On 31 December 2014 at 20:03, Mark Thomas <markt_at_apache.org> wrote:
> > - 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.
>
> I'm yet to be convinced that calling startAsync should remove a
> request/response pair from a context. I'm open to being convinced but at
> the moment I'm still of the view:
I'm not saying that startAsync should remove a request/response pair from a
context.
I'm saying that returning from a dispatch to a context should remove that
request/response pair from the context - regardless of if startAsync has
been called or not.
The only real issue I see is what is the associated context when the
dispatched thread has returned from the initial dispatched context and
startAsync has been called. So for example:
- dispatch to context A (enter A listener called & associated context is
A)
- dispatch to context B (enter B listener called & associated context is
B)
- startAsync called (associated context is still B)
- return from context B (leave B listener called & associated context is
A)
- return from context A (leave A listeners called? & associated context
is ? )
I see three options:
1. B the context that called startAsync - yuck! It's like going to the
bathroom at a party and coming out in a different party. There is also the
confusion of when the enter/exit listeners should be called - does the
request leave B then reenter?
2. A the original context that was dispatched to. This effectively
means that if the request is async, the context is never null but is left
as the last context the request was in. I'm kind of OK with this, except
that it makes the enter/exit listeners complex to implement/describe. Any
resources allocated by enter/exit resources will be held during the async
period - so we will need another set of listeners to represent the async
events.
3. no context. This is the clearest and simplest. It allows us to say
that when a dispatched thread leaves a context, the association ends and
the listeners are called and this is not dependent on any asynchronous
state.
I think currently jetty implements 3) for the listeners and 2) for the
getContextPath methods. I think my preference is for 3) which in full is:
- dispatch to context A (enter A listener called & associated context is
A)
- dispatch to context B (enter B listener called & associated context is
B)
- startAsync called (associated context is still B)
- return from context B (leave B listener called & associated context is
A)
- return from context A (leave A listener called & associated context is
null )
Simplest and forces async threads to not rely on associated contexts at all.
cheers
PS. We still have the issue of poorly named enter/exit listeners. Perhaps
we need new ones with better names and deprecate the create/destroy ones?
--
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.