On 15/11/2010 20:30, Luke Meyer wrote:
Tomcat 6.0.29, HotSpot 1.6.0_21 on CentOS 5.
I had a problem recently where someone configured a standard AJP connector
like this:
Connector port=8009 connectionTimeOut=6 acceptCount=100
maxThreads=250 protocol=AJP/1.3 /
See the typo? connectionTimeOut should be connectionTimeout. Normally
Tomcat complains when you have bogus properties, e.g.:
WARNING org.apache.tomcat.util.digester.SetPropertiesRule.begin
[SetPropertiesRule]{Server/Listener} Setting property 'aasdfhgakjs' to '1'
did not find a matching property.
But for connectors, it's silently ignored. And for an AJP connector, with no
connectionTimeout set, the default is never to timeout. Which might not be a
problem usually, but a firewall was randomly dropping connections and the
threads holding a connection were sitting there waiting forever. Eventually
the thread pool would run out and the server stopped responding to AJP
requests.
Three questions:
1) Why doesn't Tomcat complain about setting bogus connector properties?
The BIO connector doesn't complain due to how properties are handled
internally. The NIO and APR/native connector will log warnings.
2) Why is the default connectionTimeout (and thus keepaliveTimeout) on an AJP
connector forever? Combined with (1) this seems like an accident waiting to
happen.
AJP connections are intended to persistent.
3) AFAICS none of the docs on tomcat.apache.org mention that properties are
case-sensitive. I guess it's kind of obvious, but... shouldn't it be stated
somewhere?
Maybe. The configuration is via XML and XML is case sensitive. Seems
like stating the obvious to me. Also, not sure where such a statement
should be put. As always, patches welcome...
Bonus question: should any/all of these be considered bugs?
1. No. Valid configuration properties are correctly documented. It may
be possible to enhance the BIO connector to log a warning.
2. No. This is by design.
3. No.
1 and 3 are possible enhancement requests. Enhancement requests should
be entered in Bugzilla. Enhancement requests that include patches are
more likely to get applied.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
