Thinking about this a bit more I think that the extra dispatch() +
startAsync() that is possible today is actually an advantage.
A new call to startAsync() means new listeners, so it is relatively
obvious that the listener to dispatch to the error page should not be
added to the error page itself, while with what Greg is proposing you
would need some kind of guard in the listener to make sure that if
onTimeout is called a second time the timeout is not just blindly
updated.
You could say something like 'if onTimeout is called and the timout is
updated all listeners are cleared from the AsyncContext' but I think
that is getting very unintuitive.
Stuart
On Tue, Nov 1, 2016 at 1:59 AM, Mark Thomas <markt_at_apache.org> wrote:
> On 27/10/2016 06:53, Greg Wilkins wrote:
>> All,
>> we've just realized that the way the AsyncListener onTimeout (and
>> probably onError) method(s) are specified precludes an implementation
>> from writing a response asynchronously.
>>
>> The AsyncContext javadoc says:
>>
>> In the event that an asynchronous operation has timed out, the
>> container must run through these steps:
>> 1. Invoke, at their onTimeout method, all AsyncListener instances
>> registered with the ServletRequest on which the asynchronous
>> operation was initiated.
>> 2. If none of the listeners called complete or any of the dispatch
>> methods, perform an error dispatch with a status code equal to
>> HttpServletResponse.SC_INTERNAL_SERVER_ERROR.
>> 3. If no matching error page was found, or the error page did not
>> call complete or any of the dispatch methods, call complete.
>>
>>
>>
>> So once onTimeout is called, the implementation can only complete
>> (presumably after writing a blocking response) or dispatch, which would
>> then have to do another startAsync cycle if the response was to be
>> written using async IO.
>>
>> I'm wondering if we should allow AsyncContext.setTimeout to be called to
>> indicate that the current async cycle should continue with the new
>> timeout. This would allow an response to be written asynchronously.
>
> Wouldn't that make it very easy for an app to enter an infinite loop? It
> strikes me as wrong for the API to make it that easy to mess up that
> badly. Yes, you can still do this with the current API but you have to
> try a lot harder.
>
> Mark
>