Hi, >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 as >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 >wins.)
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 mode. - 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 threads. >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 of >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. Yoav 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
