[server-admins] Tomcat

DM Smith dmsmith at crosswire.org
Sun Feb 6 09:15:38 MST 2011


FYI,
This week has seen some significant changes in the setup of tomcat. Troy has implemented partitioning. It's really cool. Here is an overview of what I found:

In the past, /opt/tomcat was the running instance. Now it is merely the binary home, that is it is merely CATALINA_HOME and no longer also CATALINA_BASE.

Now the running instances of tomcat are at /opt/tomcat_site1 .. /opt/tomcat_site5.

The breakdown of the sites:
site1 - all but what's below
site2 - community
site3 - user's accounts, e.g. crosswire.org/~dmsmtih
site4 - forums
site5 - jira

The admin interface is one for each site, just append the site number after manager, e.g. crosswire.org/manager5/html.

Startup/shutdown - All instances are brought up/down together with the same command as before: /etc/rc.d/init.d/tomcat.

There is now a new /etc/rc.d/init.d/sitestart.sh and sitestop.sh. Each of these takes a number from 1 to 5, corresponding to the site. These are called by /etc/rc.d/init.d/tomcat.

In the past when tomcat went rogue and shutting down tomcat did not kill all the java processes, one had to independently kill the java processes, e.g. killall java.

Now this is a bad idea. Each instance should be managed independently from the other.

This is accomplished with: sitestop.sh N -force, where N is a site number.

Details behind this: The environment variable CATALINA_PID has the path to the file containing the PID of the java process. In our implementation it is CATALINA_PID=$CATALINA_BASE/tomcat.pid. The -force argument is provided by tomcat for the purpose of killing the process when it goes rogue.

This setup allows us to tune instances separately. For example, JIRA needs memory to be tuned to be much larger than default, with XX:MaxPermSize, -Xmx, -Xms.
These are now provided in $CATALINA_BASE/bin/setenv.sh.

Advantages:
CATALINA_HOME no is merely the home for the code. Upgrades are much simpler. It merely can be replaced.
Each CATALINA_BASE instance is independently managed.
When one of the webapps or the instance goes rogue, it only affects what is in that one instance.
Each is individually tuned. This allows for a much smaller footprint for all the instances.
The logs are much easier to understand. So many of the entries are anonymous. With community, forums, and jira in their own instances, the logs pertain only to them.

In Him,
	DM


More information about the server-admins mailing list