tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <>
Subject RE: Why is Tomcat/Connector Installation So Incredibly Painful??
Date Wed, 08 Sep 2004 14:04:53 GMT


>It wasn't the overhead of the extra thread pool that bothered me, it's
>more the fact that Tomcat would be unable to amortize thread creation
>well.  Eg. if I have one thread pool with max 75 threads for *all*
>requests, then Tomcat only has to create 75 threads, period.  But if I
>need a pool of (say) 50 threads for SSL requests and another 50 for
>non-SSL requests, then Tomcat might need to create 100 threads.  (Also,
>it's harder to know if my numbers are right -- it's like partitioning a
>hard disk into two partitions that you *think* will do the trick versus
>creating one big partition for everything.  The latter almost always

Well, even though AJP may be a better solution for you, I'll clarify a
couple of things for the good of others.

- In modern JVMs, thread creation is a fairly trivial operation.  It
takes less than 10 ms to create 100 threads on my slow Sparc box using
JDK 1.4.2 without any sort of optimization or even running in -server

- I don't know what kind of past experience you had with disk
partitions, but it's not that hard to monitor all the threads in the
JVM.  Moreover, Tomcat names them in an easy to monitor way.  I and
others have posted simple sample code to monitor all the threads in a
running JVM to this list in the past, so it should be in the archives.
My experience both on the app development and on the server development
side has been that the JVM does exactly what you tell it with respect to

>I doubt this would have much of a performance impact, and I didn't
>bother to implement and measure it.  It's just the howling inelegance
>the whole scheme that bugged me.  That was when the little "now I know
>why AJP and mod_jk exist" light bulb clicked on.  ;-)

Well, that's subjective, so I won't argue.  I find it not only elegant,
but far better than one thread pool for the whole server, but it's a
matter of stylistic preference.  I'm glad you found a good solution that
works for you, and as I said before your other argument about the
server-side redirects is strong and convincing.


This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message