As a VMware engineer dedicated to building Apache Tomcat and vFabric tc Server , I get the opportunity to see a lot of issues across the official Apache Tomcat public mailing lists, as well as VMware’s private professional support queue for both Apache Tomcat and tc Server. Typical of any software issue tracker, many of the issues logged could be avoided with a little better understanding of the Tomcat applications. Here are a few tips that may be useful to keep in mind:
There are two different types of context.xml files: one is global, and the other is specific to each web application. The problem with editing the global
context.xml file is, as its name implies, that it affects every web application running on that Tomcat instance. So for instance, if you have 10 web applications, and create a new JNDI datasource with 50 connections to the database in the global
context.xml file, you have essentially created 10 JNDI datasources with a total of 500 connections to your database and have likely completely overwhelmed your database. If you want to add a datasource to a single application, by remembering to create the datasource in the application level
context.xml file, you can avoid serious performance problems.
Occasionally companies will deploy 3 or 4 related applications on a Tomcat server that are designed to share a single datasource. As described above, placing the datasource definition either once in the global context.xml file or in 3 or 4 application specific
context.xml files will always create multiple instances of that datasource. To truly share a single datasource, it is necessary to put the definition of the datasource into the server.xml file, and then place a single resource link into the global
context.xml file. This link ensures only one instance of the datasource is ever created and when any application goes to use it, it always uses the same single instance.
In an ideal world, system administrators want three things: small heap sizes; small GC pauses and high throughput. In the real world, you get to pick any two of those but you have to sacrifice the third to get them. So if you want small GC pauses and high throughout, the price you have to pay for that is a large heap. This observation normally triggers questions about the optimum size for the Java object heap. The optimum size will vary from application to application but it is typically 4 to 5 times the minimum heap required by the application. To find the minimum heap size, look at the heap usage graphs for the application once it has reached steady state and the minimum heap required is the size the heap usage drops to just after a full garbage collection.
While it would be ideal to standardize your entire web application stack on one servlet container, the reality is that many organizations use a variety of application servers. In the case where developers are writing the applications on Tomcat, and they may not be deployed on Tomcat, they can avoid future cross-compatibility issues by setting the system property for StrictServletCompliance. This property changes a series of system defaults to follow the servlet specification very strictly to ensure portability. For more information on configuring
StrictServletCompliance see the official documentation.