Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Why does WebsocketClient work on multi threads as default?

Within a single connection, the message order (more precisely the START of the message) is guaranteed.
The only situation where this nuance is important to understand is when you are using Streaming message handling.

Each incoming message results in a new stream, that must be handled via dispatching the start of the message to your handler.
If your handling isn't fast enough, then it might seem that you are getting messages out of order, but in reality you are not.
Its just that you got the following ...

On the wire:
   [A], 1, 2, 3, 4, 5, [A-FIN], [B], 1, 2, 3, [B-FIN]

   [A]                          [B]

Your code:
   [onMessage(Stream(A))], r1, r2, r3, r4, r5, [A.close()]
                                [onMessage(Stream(B)], r1, r2, r3, [B.close()]

Which make it appear as if you got B before A finished, which is very likely and probable.
There was a time period where we would not dispatch Stream(B) until Stream(A) was closed, but this behavior was highly confusing to users of the API.
And to accomplish it we would have to stop reading from the WebSocket endpoint (even CLOSE/PING/PONG frames!) until that occurred.
Either that or we start queuing messages, especially problematic if the messages are short!

With short messages, its very probable that a single network read can result in more than 1 websocket message.
In this case, there would be multiple dispatches, in quick succession.

Joakim Erdfelt / joakim@xxxxxxxxxxx

On Tue, Dec 1, 2015 at 7:47 AM, Yohei Onishi <vivre214@xxxxxxxxx> wrote:

If WebsockectClient class is initialized without a parameter, it launches about 8 threads (1 for internal scheduling, 7 threads for working). Why is it designed to work on multi threads as default? What is typical use case for multi threads?

In my projects, we found that we could not guarantee message order with default setting (multithread) because of a context switch. For example, even if WebsocketClient receive message A then B, message B  might be processed first in a @OnWebsocketMessage callback if a context switch happens.

We care message order in my project, so we usually specify an executor like below.

WebsocketClient client = new WebsocketClient(Executors.newFixedThreadPool(2));

(Note) We need at least two threads, one for internal scheduling and the another for actual working thread.

Yohei Onishi

jetty-users mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top