jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: [servlet-spec users] Re: Re: Clarification of threading requirements of section 6.2.3

From: Greg Wilkins <gregw_at_intalio.com>
Date: Fri, 12 Dec 2014 12:38:57 +0100

On 9 December 2014 at 00:13, Stuart Douglas <stuart.w.douglas_at_gmail.com>
wrote:
>
> Basically I am talking about some kind of AsyncContext.delayStart()
> construct that will not dispatch the task until the current call stack has
> returned to the container (or just change the semantics of start() to
> match). This will make sure that only one thread is using the request and
> response, without needing to resort to synchronization or other thread
> safety constructs.
>


Stuart,

perhaps we just need another listener or another callback on the
ServletRequestListener that gives a callback when the dispatch has returned
to the container and the request is truly suspended?

We already have onWritePossible and onDataAvailable providing this semantic
if you are doing asyncIO, so we just need a callback if you are doing pure
async.

Apps can then start their async processing from this callback.

But note that it is still not safe to call many request/response methods.
What should getContextPath return when the request is not in a context and
the context that suspended it may not be the one indicated by the URI?

cheers



-- 
Greg Wilkins <gregw_at_intalio.com>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.