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?

My commentary was all about receiving messages, not sending them.
Sending them is always in order, regardless of technique, as the protocol dictates that.
(Its not possible to overlap messages in WebSocket)

Joakim Erdfelt / joakim@xxxxxxxxxxx

On Wed, Dec 2, 2015 at 8:40 AM, Yohei Onishi <vivre214@xxxxxxxxx> wrote:
Hi Joakim,

Thank you for your detailed explanation. I understand that the message order is guaranteed within the Websocket client library.
But my concern is that the message order is not guaranteed in a message callback of client code.
For example, if a context switch happens during the process of onMessage(Stream(A)), onMessage(Stream(B)) might be completed earlier than Stream(A);
# I assume that the following "onMessage" is in the same class.

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

I suppose that the only way to guarantee the message order in client code is to limit a number of thread for WebsocketClient.


Yohei Onishi

On Wed, Dec 2, 2015 at 12:38 AM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
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]

Dispatching:
   [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:
Hello,

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.

Thanks,
Yohei Onishi

_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


Back to the top