On 22 May 2013 19:20, Mark Thomas <markt_at_apache.org> wrote:
> The current sticking point is the non-blocking writes that return a
> Future. Consider the following sequence:
>
> - Container receives WebSocket message
> - Container thread triggers onMessage processing in app
> - app (still on container thread) sends a message in response using the
> Future style
> - app calls Future.get()
>
I think that the issue here is that you should not call application level
callback from an async IO callback.
async IO callbacks should not block and calling arbitrary application code
is possibly going to block with things like databases, webservices, let
alone request/response IO.
Other options I have considered:
> 1 Change the non-blocking aspects of the API in Servlet 3.1 to use the
> same style as WebSocket.
>
> 2 Expose the object being used for the one thread per request lock
> through the Servlet API so the WebSocket API can use it rather than
> its own lock to implement blocking. This could enable the Servlet API
> to detect when a container thread was blocked and therefore allow
> another thread to do some work on the same request.
>
> 3 Give up and use some the container internals directly.
>
Option 4 - to call any code that might block (eg the onMessage callback),
use AsyncContext.start(Runnable) to obtain a thread to do the call into the
application.
This allows us to keep 1 container dispatched thread limit, but that layers
like a JSR356 implementation can request another container thread to do
independent calls into application code.
--
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.