Hmmm... "No, the server will allocate maxThreads request handlers; the other requests would sit in the TCP stack's queue (not in the JVM), up to the configured acceptCount value - which you can set as high as your OS allows."
I was assuming that the tomcat main thread is going to pick it up from the TCP stack and let the web server thread handle the request. Wont tomcat reject the request when max threads have been reached (since it would have already picked up tcp layer)? On Wed, Mar 3, 2010 at 9:45 AM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: Bharath Vasudevan [mailto:bharath....@gmail.com] > > Subject: Re: Tomcat threads > > > > When tomcat gets a request, it does a socket send to some > > other process to handle the request and then respond. > > Tomcat doesn't do that - your webapp does. > > You have now introduced a previously unmentioned dependency - that the > response depends on the behavior of an external resource, unrelated to > Tomcat. That changes the picture considerably. The neat thing the servlet > 3.0 AsyncContext does is handle this case by letting you decouple the > original Request and Response objects from the original processing thread. > > > But assuming 20k client requests come in at the same time, > > the server would try to allocate 20k threads and handle it. > > No, the server will allocate maxThreads request handlers; the other > requests would sit in the TCP stack's queue (not in the JVM), up to the > configured acceptCount value - which you can set as high as your OS allows. > > > Mostly the system would trash and go down. > > Which is my point about why you don't want to set maxThreads to arbitrarily > large (or small) values. > > > But if it was to be handled gracefully, we can have the > > threads pick up the request throw it in a queue and let > > the worker threads work and respond. > > Which you can do in your webapp by sending an interim response to the > client and having the client poll for the final one. You'd have to disable > keep-alives as well. The 3.0 spec allows the container to perform this > task, rather than requiring the webapp to do so. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
