All, as much fun as it is talking about name changes, I'd like to have a discussion about the actual semantics of the API :)
We (jetty-project) are currently reviewing how we handle sendError when invoked asynchronously with an error page mapping. I'm not sure we really have the right semantic in all situations for the combinations of async caller and async error page.
Non async caller with non async error page.
This is the normal case and the error page is invoked with and ERROR dispatch from within the scope of the sendError call. After returning, the response is committed and we close the output, so no more can be written. The javadoc on says this should be considered:
* After using this method, the response should be considered
* to be committed and should not be written to.
But jetty does enforce it (and I think the TCK tests for this).
Non async caller with async error page.
Here sendError does and ERROR dispatch to the error page, which then calls startAsync and returns. Now sendError can't commit nor close the response, because it is in a race with async threads that may be writing the response. So we use an isAsyncStarted check to avoid committing/closing... so I guess that explains why the javadoc only says "considered to be ..."?
Async caller with non-async error page.
A normally dispatched request has called startAsync and then an async thread calls sendError. Current releases of jetty do an ERROR dispatch to the error page from within the scope of sendError, but we now realise that is not correct because the original dispatched thread may not yet have exited and we will end up with 1 threads inside the servlet container (and filters etc.) for the same request at the same time.
So we are considering making the error page dispatch an AsyncContext.dispatch. This solves the concurrency problem, but gives us other problems. Should the dispatch type now be ASYNC or ERROR? There is no ASYNC_ERROR! Should the calling thread call AsyncContext.complete()? Typically it will because that is the contract of async and the caller has no idea if an async dispatch is done or not inside the sendError call? So assuming they do call complete(), should we just treat it like a noop rather than ISE ?
Async caller with Async error page.
A normally dispatched request has called startAsync and then an async thread calls sendError, which does an async (or error?) dispatch to the error page that then calls startAsync again. We now how two threads that are acting on the same async request. Do we wait for both to call complete() before being complete? Surely we have to prevent a complete call from the sendError thread from completing the async cycle of the error page startAsync? What if one of them calls AsyncContext.dispatch? At this point we are thinking that once a request goes async, then perhaps we should never dispatch to an error page from sendError and instead just generate our own simple error page?
I'd love to know what the other containers do in these situations?
I think we obviously need to at least be more specific in our javadoc, but I'm thinking that perhaps we might need to change behaviour as well to avoid async on async error pages?
regards
--
