On 02/09/2016 15:47, Romain Manni-Bucau wrote:
> ~business code (simplified):
>
> public void myBusiness(AsyncResponse wrapperOfAsyncContext) {
> new Thread() {
> @Override
> public void run() {
> wrapperOfAsyncContext.synchronizedDispatch();
> }
> }.start();
> wrapperOfAsyncContext.synchronizedMethod();
> }
>
> If timing is good (and encountered enough to say it is in real life) then
> both method call will lock cause:
>
> 1. for the user thread: the dispatch call will call pauseNonContainerThread
> to wait the myBusiness thread to end (actually a bit more but you get the
> idea)
> 2. synchronizedMethod will lock on synchronizedDispatch
>
> so synchronizedMethod is lock on synchronizedDispatch which is lock on
> the pauseNonContainerThread of the caller/http thread so both threads are
> locked.
Hmm.
The relevant text from the Servlet spec is (for both dispatch() and
complete()) is:
"If any of the dispatch methods are called before the
container-initiated dispatch that called startAsync has returned to the
container, then the call will not take effect until after the
container-initiated dispatch has returned to the container."
The critical question is what does "...will not take effect until..." mean.
Currently, Tomcat implements this as "...will block until...". I'll look
into what it would take to implement this as "...note the request and
execute it once...". Whether or not we change this will depend a lot on
how complicated the change would be.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
