On 17 May 2013 19:25, Rémy Maucherat <rmaucher_at_redhat.com> wrote:
> Looking at some of the more creative uses of the API, like websockets,
> Mark found some issues and there has been a discussion about having
> concurrent read/write, or autoblocking (both should allow implementing
> websockets, but experimentation is ongoing).
I've read that thread lots of interesting points raised but no clear
conclusion. This is a really a significant part of any implementation, so
I think it is very important that we clarify what is allowable ASAP.
Currently as the spec is written, it implies that only a single thread can
be in either a servlet dispatch, a read callback or a write callback.
Another way of saying that is that once asynchronous IO is initiated, the
container expects that the application will not block in servlet dispatch
or any read/write callbacks, as to do so will prevent other calls being
made.
As Mark says, this is a limitation that will prevent things like simulating
blocking APIs with the async IO or even mixing blocking input with async
output. However, the AsyncContext#start(Runnable) method is available
and we could always say that an application that wishes to block should use
that API to access a different thread. So for example the JSR356
implementation should not callback websocket methods directly from IO
callbacks nor servlet dispatch as those callbacks could use a blocking
websocket API. Instead the JSR356 implementation should use
AsyncContext#start(Runnable) to access other threads to do those callbacks,
which are free to block.
We could say that we will move this thread dispatch mechanism to the
container so that applications need not have to deal with dispatching
threads themselves, but that would mean that all IO callbacks would have to
be dispatched with a thread that we can allow to block. That means that
we pay a price even if we don't have any blocking in our callbacks. So
I think I prefer that we stick with how the spec is written and only allow
a single thread. We just need to be more explicit in a MR that the
callbacks cannot block and should use AsyncContext#start if they have
might.
I also think that this means that the initial callbacks to onWritePossible
onReadPossible should not happen until after the thread dispatched to the
servlet returns.
cheers
--
Greg Wilkins <gregw_at_intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.
Intalio, the modern way to build business applications.