That's very illuminating, thanks. I was looking at the table at the bottom of http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html#NIO_specific_configuration, and got the impression APR was blocking also, but now I see 'waiting for next request' is non-blocking in the TC7 table.
Would you give us a sense of how using a non-blocking connector would be important when doing comet? Once startAsync is called, will the standard (blocking) connector continue to hold resources (where the NIO connectors won't)? Thanks, Matt On Wed, Nov 9, 2011 at 1:24 AM, <ma...@apache.org> wrote: > Matthew Tyson <matthewcarlty...@gmail.com> wrote: > > >I guess what I'm asking is if I just start using the Servlet 3.0 > >support > >for suspending requests out of the box, will it be a thread blocking > >implementation I'm using? > > That depends what you mean by "thread blocking". Once startAsync has been > called the thread that was processing the request/response is released to > handle other requests regardless of connector. > > >HTTP APR/native is blocking as well, correct? > > Wrong. You should read the docs, particularly the summary at the bottom of > the HTTP connector configuration page > > >So if I want to use Servlet 3.0 async (eg, a call to > >request.startAsync), > >and have it be handled without blocking IO, I need to use the NIO > >connector? > > Wrong again. All Servlet IO is blocking IO. If you look at the API you'll > see that all read and write calls are blocking. > > You seem to be mixing up blocking and non-blocking IO with whether or not > a thread is dedicated to processing a request/reponse pair for the life of > the request/response. They are very different beasts. > > All connectors release the thread to handle other requests once startAsync > has been called. > > As an aside, the non-blocking connectors will use non-blocking IO where > they can but once you get to the Servlet API, that is always blocking IO. > > Mark > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
