Well it is not different and both should be allowed IMO, i just tried to find a solution for the original bug without breaking common usages. It should be easy to reproduce with a servlet: GET /foo?start=true -> create an async context then GET /foo?continuer=true -> resume without popping a new thread. nothing will happen.
Well said otherwise: why tomcat is preventing to continue a request in a container thread? If this is for an internal reason (issue mentionned by Konstantin) then it is a bug. Point is ATM this feature doesn't work and AFAIK it is not fobidden by the spec. Another point is startAsync works but you reuse container pool (so previous issue sounds really like a bug). startAsync works cause the context (this marker flag) is generally different (not set) when you call it. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-11 10:15 GMT+01:00 Mark Thomas <ma...@apache.org>: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
