On 23/05/2013 09:50, Rémy Maucherat wrote:
> On 05/23/2013 12:57 AM, Greg Wilkins wrote:
>> 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.
In an ideal world yes, but that looks like it would need some API
changes unless I am missing something (keeping in mind my aim is to
implement WebSocket on top of Servlet 3.1 without using any container
specific API).
>> 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.
>>
> I mentioned that in an earlier message, but I don't think AsyncContext
> is available in upgraded mode ...
That was exactly what I thought when I read Greg's suggestion. I'd
prefer something like this approach. In addition to the AsyncContext not
being available, if it were available it is a relatively heavy-weight
object for use in an upgrade scenario. Adding start(Runnable) to
HttpUpgradeHandler looks like it would do the trick.
Mark