tomcat

Configuring the Tomcat manager webapp

I like to have the Tomcat manager webapp installed on each instance, so I can play with the webapps, and see how many active sessions there are. To do this, make a file called manager.xml file in the webapps directory of your Tomcat instance. One I like to use is this:

    <Context path="/manager"
        docBase="/usr/local/tomcat/server/webapps/manager"
        debug="0"
        privileged="true">

    <ResourceLink name="users"
            global="UserDatabase"
            type="org.apache.catalina.UserDatabase"/>

    <Valve className="org.apache.catalina.valves.RemoteAddrValve"

Running multiple Tomcat instances on one server

Here's a brief step by step guide to running more than one instance of Tomcat on a single machine.

Step 1: Install the Tomcat files

Download Tomcat 4.1 or 5.5, and unzip it into an appropriate directory. I usually put it in /usr/local, so it ends up in a directory called /usr/local/apache-tomcat-5.5.17 (5.5.17 being the current version as of this writing), and make a symlink named /usr/local/tomcat to that directory. When later versions come out, I can unzip them and relink, leaving the older version in case things don't work out (which rarely if ever happens, but I'm paranoid).

Connecting Apache and Tomcat using mod_proxy

The Tomcat documentation page is a resource to keep somewhere. I will also write it up into the Admin Guide.

Tightening the Default Tomcat Configuration

Basic things to do to tighten up the Tomcat configuration. Out of the box it's not really set up for production use.

Remove unnecessary webapps

Strip down the server.xml

Take out connectors you don't need. Get rid of comments to make it easier to follow. Strip the examples code. What user account functionality do you need for your apps, and for the server admin/management tools if you use them?

Some basic tuning

Reloadability and such. Logging. Connector tweaking.

Tomcat Log Management

One of the drawbacks of the default Tomcat setup is that the logfiles aren't written to the sensible location on Unix and Linux systems. This isn't hard to correct.

Here's how. (Examples of configuration settings in server.xml and so on go here).

While you're at it, you should consider tweaking what logs are written.

Different types of logs you can have.

Recommendations for paring it down for production.

Tweaks to make for debugging.

What you may want on development.

Tweaking the log4j configuration to control what you log.

Retention policy. Decide how long you want to keep your logs. Important logs, e.g. where you have applications write data that need to be collated and reported on for business reasons, should be archived.

Tomcat Startup Scripts - Introduction

Making all this work needs control scripts to start and stop your server. The scripts that come with Tomcat are fine at a rough level. You set up a couple of environment variables and away you go. But they have some drawbacks.

The benefits of having your own scripts that call the catalina scripts are:

  • Make sure the server runs as the appropriate user
  • Easily have multiple different configurations, with different CATALINA_BASE directories, with different applications and/or configurations. You can also have different versions of the JVM and Tomcat with the flip of a switch. Useful for servers with multiple applications, and also for development setups where you need to be able to switch the application quickly.

Accounts and ownership

This mainly pertains to Unix and Linux systems. One of the cardinal rules is never run Tomcat as root, but I'm sorry to say I've seen this in live production systems.

Why not?

We'll walk you through setting your system up so you can run as a non-root user.

Potential separate roles:

  • Installation file owner
  • Server runtime user
  • Webapps user
  • Server administrator user

The installation files owner owns the CATALINA_HOME directory. It is often root, which is fine since no processes need to run as this user. The other user accounts shouldn't be able to write to these files.

Splitting your Tomcat installation for more power

The most basic setup of Tomcat involves unzipping the distribution files somewhere on your system, dropping your application into the webapps directory, and firing the server up. This is a fine quick start to run a single app on your own machine, but Tomcat offers a much more powerful way to organize production servers and complex developer setups.

If you read down a ways in the RUNNING.txt file in the tomcat installation bundle, you’ll find a section called “Advanced Configuration - Multiple Tomcat Instances”. This describes how to split your Tomcat installation into two directories, the $CATALINA_HOME directory for the Tomcat installation files, and the $CATALINA_BASE directory with the runtime files. Setting these two environment variables when you start up Tomcat controls where the server will look for its files.

Advanced Tomcat Setup Notes

It's easy to just unzip the Tomcat installation files, drop your webapp into place, and start up the server. But although that works fine for a quick start, once you get into production use, or more complex development scenarios, there are some basic things you can do to make your life easier.

Putting Tomcat into Production

Installing and configuring Tomcat is fairly straightforward if you follow the documentation that comes with it. But putting it into production requires more thought if you want to make sure you have restful nights and more productive days.

This guide is intended to help systems administrators and Java developers who are responsible for applications running on Tomcat in production to make sure their serves are stable, fast, and easy to manage.

Syndicate content