Hi, That was an excellent message. Your approach is flawless. You can keep using your hack, which isn't that crude at all. You can keep using the 5.x Connector code by and large with 4.1.30 (though not earlier versions of Tomcat 4.1), it should be just fine. And I tend to agree than 10 as MAX_THREADS_MIN is too high: something like 2 or 3 seems reasonable to me. Please open a Bugzilla item asking for this to be modified, and I will address it. Thanks,
Yoav Shapira Millennium Research Informatics >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Sent: Tuesday, August 03, 2004 5:30 PM >To: [EMAIL PROTECTED] >Subject: Tomcat 4.1.30 ThreadPool.adjustLimits > >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: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] 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]
