tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bharath Vasudevan <>
Subject Re: Tomcat threads
Date Wed, 03 Mar 2010 17:21:19 GMT
Hi Charles,

Let me explain the scenario. When tomcat gets a request, it does a socket
send to some other process to handle the request and then respond. This
would happen fast. But assuming 20k client requests come in at the same
time, the server would try to allocate 20k threads and handle it. Mostly the
system would trash and go down.

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. Let
me know if I am missing something here.


On Tue, Mar 2, 2010 at 7:22 PM, Caldarale, Charles R <> wrote:

> > From: Bharath Vasudevan []
> > Subject: Re: Tomcat threads
> >
> > Why is it illlogical?
> 40+ years of system architecture experience.
> > If the number of requests increases, the number of threads
> > that can be handled by the system goes down.
> You'll have to explain that one, since it doesn't make sense as written.
> > The context switches and the pain to handle the switches makes
> > handling of the requests in lesser threads which is scalable.
> Nor does that.  What are you categorizing as a "lesser thread"?  What makes
> those any more scalable than any other kind of thread?  You're free to set
> the thread pool limit to any value you want, including infinity.  Setting
> the limit to larger than what the logical and physical resources of the
> system you're running on can handle will induce performance problems (e.g.,
> page thrashing, excessive GCs) or outright failures as soon as someone
> decides to start pounding on your server.
>  - Chuck
> 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message