On 19 December 2014 at 10:30, Mark Thomas <markt_at_apache.org> wrote:
> I like an earlier suggestion that calls to asyncContext.start(Runnable)
> do not take effect until the container thread exists the context. That
> solves a number of concurrency issues. Is there agreement on this? Is it
> worth spinning this particular point out into a separate thread?
>
I like that semantic, but don't think we should change the existing method.
Instead we could add either something like startDelayed(Runnable) but I
don't like
the name, but can't think of a better one; OR start(Runnable runnable,
boolean delayed)
which is a touch ugly also, but would allow us to deprecate the existing
start(Runnable), so it was clear to users that they need to consider which
version they want.
[snip]
Getting back to your original point which you expanded on above, I've
> always though of the request remaining with the context associated with
> the request when async started until it is moved to a different context
> with a dispatch.
>
But the problem remains that there is no "the" context that is associated
with a request that can be replaced. Is it the context that called
startAsync? Is it the originally dispatched context? Is it the context
that the request is currently dispatched to? Note also that the async
dispatch to the new context can happen while the request is any of those 3
contexts!
Thus I think that at any given time, there is "a" context associated with a
request and that is the context that the request is currently synchronously
dispatched to. When there is no synchronous dispatch, then we need to
define which is the associated context - I don't think any of the possible
contexts (original / async started / dispatch destination ) are correct, so
I would prefer to say that no context is associated with a request that is
not synchronously dispatched. We should define which methods are context
related and perhaps they should throw ISE if called outside of a context?
> Mark
>
>
--
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.