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).
--
Greg Wilkins <gregw_at_intalio.com>
www.webtide.com
Developer advice, services and support
from the Jetty & CometD experts.