> 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
