Clarify ordering, concurrency behavior of WebSocketListener and normal HTTP responses

[cowwoc]

I have some thread-safety questions about the behavior of websocket responses and normal HTTP responses. These do not seem to be answered by the Javadoc or any other documentation I have seen.

1. Are responses guaranteed to be delivered to event listeners in the same order that they are received by the network? I assume yes.
2. If two responses arrive sequentially, but the first event listener has not returned yet, does the second response block until the first response is complete? Or do you fire the event in a second thread?
3. If you fire events in different threads, what guarantee is there that event listeners can record the order in which messages were received which (in the case of websocket responses at least) might be significant?

I'm wondering these questions myself, but I'd also like to see them documented more officially too. Thank you.

[joakime]

The answer is ... "it depends".

If you are using By-Frame, Partial, or Whole Message delivery to your WebSocket endpoint, then yes, order is guaranteed.
The implementation waits for the call to the method declared on your WebSocket endpoint to return before continuing to parse the network buffer for websocket frames.
This is essentially a single threaded delivery setup.

If you are using Streaming message delivery, then the start of each message is dispatched to a new thread to your WebSocket endpoint as the type of Stream (InputStream, Reader, etc) you are interested in.
With Streaming message delivery, the general java behavior with starting multiple threads starts to become a factor.

Lets say you have a single network buffer.

This is how it typically is.

1. WebSocket parsing begins.
2. WebSocket Frame is parsed.
3. If WebSocket Frame indicating a new WebSocket Message is encountered, begin WebSocket Endpoint delivery
   1. Stream object (Reader / InputStream / etc) is created.
   2. Stream object is dispatched (via a new thread) to your WebSocket endpoint.
4. If WebSocket Frame is continuation, offer Frame buffer to last Stream type.
5. If WebSocket Frame is FIN==true (final), continue parsing.
6. Loop to step 1.

Now, if you have quick messages, and Streaming, its possible for thread dispatch to be suspended just long enough for the next new message to be delivered before the prior new message.
This typically isn't a problem with a series of large messages, or the more common use case for streaming where its just 1 giant message (webrtc/voip/gaming/video/etc).

[cowwoc]

Excellent answer. Thank you. Can we document this somewhere? :) Javadoc? Stackoverflow? Somewhere else?

…

On Mon, Jul 2, 2018, 09:02 Joakim Erdfelt, ***@***.***> wrote: The answer is ... "it depends". If you are using By-Frame, Partial, or Whole Message delivery to your WebSocket endpoint, then yes, order is guaranteed. The implementation waits for the call to the method declared on your WebSocket endpoint to return before continuing to parse the network buffer for websocket frames. This is essentially a single threaded delivery setup. If you are using Streaming message delivery, then the start of each message is dispatched to a new thread to your WebSocket endpoint as the type of Stream (InputStream, Reader, etc) you are interested in. With Streaming message deliver, the behavior of threading starts to kick in. Lets say you have a single network buffer. This is how it typically is. 1. WebSocket parsing begins. 2. WebSocket Frame is parsed. 3. If WebSocket Frame indicating a new WebSocket Message is encountered, begin WebSocket Endpoint delivery 1. Stream object (Reader / InputStream / etc) is created. 2. Stream object is dispatched (via a new thread) to your WebSocket endpoint. 4. If WebSocket Frame is continuation, offer Frame buffer to last Stream type. 5. If WebSocket Frame is FIN==true (final), continue parsing. 6. Loop to step 1. Now, if you have quick messages, and Streaming, its possible for thread dispatch to be suspended just long enough for the next new message to be delivered before the prior new message. This typically isn't a problem with a series of large messages, or the more common use case for streaming where its just 1 giant message (webrtc/voip/gaming/video/etc). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2690 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAmqBHnVfBCMttKBJtosJW1w4oOVthcTks5uChntgaJpZM4U_PpY> .

[stale]

This issue has been automatically marked as stale because it has been a full year without activit. It will be closed if no further activity occurs. Thank you for your contributions.

[joakime]

This is a documentation issue, removing Stale to keep it alive.

[stale]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lachlan-roberts]

Now, if you have quick messages, and Streaming, its possible for thread dispatch to be suspended just long enough for the next new message to be delivered before the prior new message.

This was since classified as a bug and has been fixed. We will not dispatch the thread for the next message until the thread for the previous message leaves its onMessage() method. The messages should be received one at a time and in the same order they were sent.