On 30/12/2014 22:39, Greg Wilkins wrote:
>
>
> On 19 December 2014 at 10:30, Mark Thomas <markt_at_apache.org
> <mailto: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.
I don't view this as changing the current method but clarifying how it
should behave.
> 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.
In order of preference:
a) clarify the existing method
b) add start(Runnable, boolean), deprecate start(Runnable)
c) add startDelayed(Runnable)
My primary concern is adding clarity where there are currently gaps so
I'd be happy with any of these as long as the timing of the starting of
the thread for the existing method and any new method was made clear in
the spec.
> [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!
Ah. I think you were inferring meaning from my use of "the" that wasn't
intended.
> 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.
That I agree with.
> When there is no synchronous dispatch,
> then we need to define which is the associated context
Also agreed.
> - 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:
- associated with Context A
- startAsync()
- still associated with Context A
- dispatch(to context B)
- associated with context B
(where A may equal B)
> We
> should define which methods are context related and perhaps they should
> throw ISE if called outside of a context?
If async requests are considered to be outside of a context then I agree
with the above (but I'm not yet convinced of that).
Mark