Correctly placing and referencing TLD libraries
Tomcat 5.5 documentation indicates that JAR files containing libraries should be stored in the webapps META-INF directory, per the JSP specification:
The DisableReuse + JKOption is recommended because of how mod_jk handles connections. Typically the DisableReuse option is recommended when there are issues with keeping a connection alive.
mod_jk has built in health checks:
Both of them do the same thing. They send a PING to Tomcat. Tomcat responds with a PONG. And only then the connection is used as it is considered healthy.
Why active threads remain high after load decreases using the Blocking IO connector
There are a number of different http connectors that can be used with Tomcat. They are:
• Blocking IO
• Non-blocking IO
• Native/Apache Portable Runtime (APR)
The blocking IO connector is the default http connector. With this connector each request is handled by a dedicated thread (obtained from a pool) until the request is complete at which point the thread is returned to the pool to be re-used by another request.
Understanding mod_jk, mod_proxy, and mod_proxy_ajp
There are three main modules available for connecting Apache to Tomcat:
This module has the load balancing capability that was not supported in mod_proxy prior to Apache 2.2. The use of mod_proxy_ajp is preferred over mod_jk for Apache 2.2 or later.
For further documentation on mod_jk, see the official documentation as provided by the Apache Software Foundation:
Working with mod_jk: http://tomcat.apache.org/tomcat-3.3-doc/mod_jk-howto.html
Understanding the role of the community, ASF, and Enterprise Tomcat vendors
Yes, bothTomcat 5.5.x and 6.0.x are thoroughly tested by the ASF community. Community testing is both ad hoc, that is, community users testing the new versions on their existing applications, as well as via the Java Community Process Technology Compatibility Kit (TCK) for the corresponding Servlet and JSP specifications. You can find high level information on the TCK program at:
The importance of server date and time in deploying JSP pages
The problem very likely is caused by timestamp mismatch. The newly uploaded JSP page or servlet has an older timestamp than that of the cached page or servlet on the server. To avoid the problem, ensure the system clock on the machine where the JSP or servlet uploaded from is in sync with the system clock of the machine where the server is running on. To remedy the problem, check the following: