tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Caldarale, Charles R" <>
Subject RE: Tomcat threads
Date Wed, 03 Mar 2010 17:45:34 GMT
> From: Bharath Vasudevan []
> 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)

> 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

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:
For additional commands, e-mail:

View raw message