tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jbla...@graphtronics.net
Subject Tomcat 4.1.30 ThreadPool.adjustLimits
Date Tue, 03 Aug 2004 21:29:59 GMT
I have several questions that apparently center around the 
org.apache.tomcat.util.threads.ThreadPool class contained in the 
tomcat-util.jar file included in the Tomcat V4.1.30 distribution. 

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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message