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 / joa...@webtide.com
On Tue, Dec 1, 2015 at 7:47 AM, Yohei Onishi <vivre...@gmail.com> 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@eclipse.org
> 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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
