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
