All,
I'm just wondering how other implementations resolve the race that exists between a call to `AsyncListener.onTimeout` and the application calling `AsyncContext.dispatch`.
This is a natural race that exists because the application may decide to act at the very moment that the async timeout occurs. However, the servlet spec has made it difficult to handle nicely since it allows the application to call `AsyncContext.dispatch` from within it's `AsyncListener.onTimeout` implementation.
This means that the container must allow a call to dispatch after a timeout has occurred, but if it is actually the application calling dispatch and not the onTimeout handler, then it is the wrong dispatch! If it is allowed, then the application may see both the correct handling of its dispatch call AND a call to onTimeout, which might not call dispatch at all.
This is a race that happens rarely and in Jetty we have ignored it up until recently. However, we now have decided that ignoring the race is the wrong thing to do. Instead, after a timeout, we only allow calls to dispatch or complete from the thread that is currently calling a onTimeout listener. Any other threads calling dispatch or complete will get an ISE.
Is this something other containers do? Should we document in the spec? Is there anyway we can resolve this race in the API?
regards
--
