4 Mistakes To Avoid On Apache Tomcat

posted by mthomas on August 3, 2011 06:50 AM

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:

Understanding Global vs Application Context.xml Files

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.

Creating a Single Global Datasource for Application Sharing

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.

Optimizing Garbage Collection with Heap

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.

Developing and Deploying on Multiple Servlet Containers

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.

Mark Thomas is a Senior Software Engineer for the SpringSource Division of VMware, Inc. (NYSE: VMW). Mark has been using and developing Tomcat for over six years. He first got involved in the development of Tomcat when he needed better control over the SSL configuration than was available at the time. After fixing that first bug, he started working his way through the remaining Tomcat bugs and is still going. Along the way Mark has become a Tomcat committer and PMC member, volunteered to be the Tomcat 4 & 7 release manager, created the Tomcat security pages, become a member of the ASF and joined the Apache Security Committee. He also helps maintain the ASF's Bugzilla instances. Mark has a MEng in Electronic and Electrical Engineering from the University of Birmingham, United Kingdom.