jsr356-experts@websocket-spec.java.net

[jsr356-experts] Re: Multithreading Options

From: Mark Thomas <mark_at_homeinbox.net>
Date: Sun, 05 Aug 2012 10:05:30 +0100

Resending from the right address.

On 13/07/2012 03:44, Greg Wilkins wrote:
> Danny,
>
> Firstly I think we need to be careful about using the word "socket", as we
> are likely to have to deal with MUX soon, so I think it far better to use
> "session" or "channel" or "stream"... I'll use "stream" below as that is
> what SPDY uses.
>
> With mux, we have to ensure that a slow message handler on one stream does
> not prevent another stream from progressing - so we are probably going to
> have the situation where the thread that parses the websocket stream will
> have to dispatch to another thread to call whatever onMessage(ByteBuffer
> out) API we come up with.
>
> So assuming we want applications to be unaware if they are working on a
> MUX'd stream or not, then the semantics should be the same. Since the MUX
> case has an allocated thread, this implies that in all cases the
> application can assume that any thread calling an onMessage API can be used
> for long running operations (block on DB write for example).
>
> However, I also think that it is reasonable to limit each stream to have a
> single dispatched thread, so that we will not get concurrent calls to
> onMessage and a subsequent call will wait for the previous to return. If
> any application wants to process messages concurrently, then it can
> dispatch to its own executor in onMessage. Note also that I think this
> contract is good for buffer ownership as well - whilst in an onMessage
> call, the application can assume that the ByteBuffer passed to it will not
> change. But if it wants to dispatch the handling of the message to another
> thread, then it must take a copy of that data as the buffer may be reused
> by the caller as it parses other frames in its buffer.
>
>
> Note that restricting a single callback per stream does not mean that a
> websocket endpoint object cannot be shared between multiple streams and
> thus receive concurrent callbacks (more like the servlet model).

That all sounds reasonable to me. It does, however, raise a question. In
the mux case where we have a client that is sending data faster than the
application can process it on one of the mux'd streams, how does the
client get signaled to slow down? In the non-mux case, we can just stop
reading the data but in the mux case that impacts all the other streams
as well.

Mark