On 11/02/2015 07:58, Romain Manni-Bucau wrote: > Well in two words if you take the most common example of JAXRS 2 > continuation (@Suspended) it will do it (doing the link with > servlets): > > -> request 1 -> suspend async context > -> request 2 -> async context dispatch (resume) > > issue is that resume is called from request 2. In other words > ContainerThreadMarker should check current thread id and not just a > boolean cause request 2 is in a container thread but this is not > request 1 thread so you can do request 1 async operations in it. > > wdyt? hope it is clearer
Nope. I still don't see what the problem is or why forcing a dispatch to a different container thread is any different to continuing to execute on the current container thread. Mark > > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-11 0:16 GMT+01:00 Mark Thomas <ma...@apache.org>: >> On 10/02/2015 23:06, Konstantin Kolinko wrote: >>> 2015-02-10 14:16 GMT+03:00 Romain Manni-Bucau <rmannibu...@gmail.com>: >>>> Hi guys, >>>> >>>> in org.apache.coyote.AsyncStateMachine#asyncDispatch tomcat checks >>>> ContainerThreadMarker.isContainerThread() >>>> >>>> basically it prevents to use JAXRS 2 @Suspended without creating >>>> custom threads - which is not intended. >>> >>> I do not know what the above is about. >> >> Me neither. >> >>>> Was this limitation intended or just to try to avoid to consume >>>> container threads? >> >> In addition to the reason Konstantin explains below, it is also a >> performance benefit. If we are already on a container thread and need to >> process a dispatch() it is much more efficient to stay on that container >> thread to process the dispatch() than it is to return the current >> container thread to the pool, monkey about with the poller (or >> equivalent for the connector in question) to trigger an event, wait for >> the event to fire and poller to allocate the socket to a container >> thread and then process the dispatch. >> >> Mark >> >> >>> >>> Looking at blame results, those lines were added in >>> http://svn.apache.org/r1594198 >>> "Address root cause of ReadPendingException rather than swallowing it." >>> >>> Discussion that preceded that commit is in "Re:r1593303" thread, >>> http://tomcat.markmail.org/thread/4kwnhzwhhxi43sob >>> >>> <quote> >>> I think I have got to the bottom of this. An async dispatch always >>> adds the socket to the poller but if the dispatch occurs on a >>> container thread then it will also be added to the poller when that >>> thread exits the AbstractConnectionHandler.process() method. >>> >>> This looks like a bug with all the connectors but one that is more >>> obvious with Nio2 because it triggers the ReadPendingException. Fixing >>> this bug highlighted a minor issue on shutdown. I have a fix for that >>> too. Commits to follow shortly. >>> </quote> >>> >>> Best regards, >>> Konstantin Kolinko >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
