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]
