Background:
Using V4.1.30 in a standalone, relatively minimal configuration with the Coyote HTTP/1.1 Connector. Deployed on several hundred (ultimately several thousand) UNIX servers of various flavors. Least common denominator server types supporting only JVM 1.2.2 limit us to 4.x Tomcat. Tomcat used solely for foreign system access to server data via specialized servlets in a confined/controlled environment (not internet exposed). Resource considerations require limiting Tomcat to a tiny fraction of it's concurrent connection capacity (primary function of servers is to host a vast load of multi-user business management applications). What I'm after is limiting to a max of 4 concurrent connections on the "stock" configuration.
Initially though I could simply set maxProcessors="5" and minProcessors="1" (earlier experimentation suggested actual concurrent connections was one less than maxProcessors value). I unfortunately misinterpreted the warning message generated during startup, "WARNING: maxThreads setting (5) too low, set to 10", to be a suggestion. I now understand this is a statement that Tomcat (ThreadPool.adjustLimits() method logic, in particular) actually reset the maxProcessors value to 10.
Went looking for ThreadPool in V4.1.30 source (based on warning message origin tags) without success, then remembered something about TC V4.1.30 using TC V5.x Coyote connector. Then located what I believe to be the operative logic in jakarta-tomcat-connectors portion of Tomcat V5.0.19 source (version I happened to have handy). Sure enough, method adjustLimits() forces maxThreads value (apparently set by digester logic based on TC4.x.x maxProcessors) to MAX_THREADS_MIN (hardwired to 10 in source) if value supplied in server.xml is less than that.
I knocked off a copy of org.apache.tomcat.util.threads.ThreadPool, changed MAX_THREADS_MIN to 2, compiled, and surgically deployed resulting classes under server/classes (effectively overriding the ThreadPool class in server/lib/tomcat-util.jar) on a test box. Appears to be behaving reasonably, now limiting concurrent connections to that specified in server.xml file. I know - crude hack - but I didn't have much recourse without fielding something to front-end Tomcat.
My questions:
(1) Is there some other reason for this essentially arbitrary (upward) adjustment of the maxProcessors/maxThreads value - beyond the rational provided in the source commentary "... fix provides reasonable settings for a single CPU with medium load."?
(2) Is the ThreadPool source from Tomcat V5.0.19 the appropriate "version" to use as I have outlined above? (It appeared to be the closest date match to the Tomcat V4.1.30 release, but I couldn't find any specific references to where the tomcat-util.jar file in V4.1.30 originated.)
While my little "hack" appears to be working - I'm still testing the crap out of it - would be nice to know if there is something I may have missed, so any input from those intimate with V4.1.30 & V5.x logic would be most appreciated.
Regards,
Jim Layer
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
