Closed shaotaoliu closed 2 months ago
Hi @shaotaoliu , thanks for reporting this.
Hi @tanderson-ld, thank you for your reply.
I'm using the package LDSwiftEventSource.
Yes, see the logs below:
Starting EventSource client initial reply received State: raw -> open Opened Connection unexpectedly closed. State: open -> closed Waiting 1.7817 seconds before reconnecting... Closed Starting EventSource client initial reply received State: closed -> open Opened Connection unexpectedly closed. State: open -> closed Closed Waiting 3.4727 seconds before reconnecting... Starting EventSource client initial reply received State: closed -> open Opened Connection unexpectedly closed. State: open -> closed Closed Waiting 7.2460 seconds before reconnecting... ......
data: {"chatId":"550e8400-e29b-41d4-a716-446655440000","gid":"123e4567-e89b-12d3-a456-426614174000","seq":1,"type":"text","value":{"text":"Your credit file is locked.","metadata":{}},"last":false}
Hi @tanderson-ld What happens if the server closes the connection after finishing sending the events? Will the above urlSession function be called?
Hi @tanderson-ld What happens if the server closes the connection after finishing sending the events? Will the above urlSession function be called?
It does appear so.
If the data is being transmitted in full, but onMessage is not triggering, perhaps the data is not properly terminated. Is this a custom SSE server implementation? If so, I recommend reviewing this specification.
Lines must be separated by either a U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF) character pair, a single U+000A LINE FEED (LF) character, or a single U+000D CARRIAGE RETURN (CR) character.
Since connections established to remote servers for such resources are expected to be long-lived, UAs should ensure that appropriate buffering is used. In particular, while line buffering with lines are defined to end with a single U+000A LINE FEED (LF) character is safe, block buffering or line buffering with different expected line endings can cause delays in event dispatch.
@tanderson-ld Actually the onMessage function is called, sorry for the mistake. It seems that LDSwiftEventSource expects the client closes the connection, so what should I do in the following two scenarios?
My second question looks like the pooling or long-pooling described here: https://eclipse-ee4j.github.io/jersey.github.io/documentation/3.0.0/sse.html#:~:text=If%20the%20server%20has%20no,a%20request%20to%20a%20server.
You may need to fork this repo and make modifications to meet your needs.
The open method is called and the response is returned successfully, but then the following function is called (and so the onMessage is not reached)
public func urlSession(_ session: URLSession, task: URLSessionTask, didCompleteWithError error: Error?)
The error is nil, so it reconnects and keeps re-calling the API even if the API is successful. Is it a bug?