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