High availability Tomcat

Connect Tomcat servers to Apache and to each other to keep your site running

1 2 Page 2
Page 2 of 2

Go to /jkstatus, and you should notice a message in the top left corner saying something like:

  Updated config version to 4 Status information for child 6

You should also see that the disabled field for server2 is set. Server2 will no longer accept any new sessions. Similarly, we could add a new Tomcat to the cluster by adding a new channel.socket entry.

By changing the owner of workers2.properties, we could edit it and reload it into the server without ever needing to reboot. We could add or remove cluster workers from an Ant or Maven task, from a shell script, from a CGI script, or even from a scheduled task such as a Unix cron job. Heck, we could even write a script that parsed Apache's log, calculated the current average load, and added or removed Tomcat workers as needed!

Simple scenarios

In the current setup, the two servers equally share the work. If server2 were on a less powerful machine, we might want to give it a lower percentage of the traffic. What percentage of the traffic a worker receives is set via the channel.socket element's lb_factor property. The smaller the number, the more often Tomcat will receive requests. The lb_factor property defaults to 1. To reduce server2's load, edit its entry to:

  [channel.socket:server2]
   host=127.0.0.1
   port=8010
   tomcatId=server2
   ver=1
   lb_factor=2

The other scenaro we might need is failover. For server2 to receive requests only if server1 fails, use the level property:

  [channel.socket:server1]
   host=127.0.0.1
   port=8009
   tomcatId=server1
   level=0
   ver=2
   [channel.socket:server2]
   host=127.0.0.1
   port=8010
   tomcatId=server2
   ver=2
   level=1

The level can be 0-3. All the lower-numbered levels are checked before any higher levels receive a request. Server2 will receive requests only if server1 no longer responds.

Note that we change the ver number for each edit so that jkstatus will reload the file.

Cleaning up

Having tested our Apache/Tomcat cluster, we can tidy up the server.xml. You can comment out the HTTP connector in the server.xml file, as it should not be accessible in production use. Another option is to use firewall rules to block those ports from the outside world. Then we can keep the connector for use in testing or for accessing administration applications not mapped by a [uri:] element in the workers2.properties file.

Troubleshooting resources

Conclusion

We started with one instance of Tomcat and lost traffic whenever we needed to work on it. Now we have Apache with any number of Tomcat workers behind it, and we can stop and start these at will. Requests and sessions are safe. We can change the cluster settings without restarting Apache.

A few years ago, you could only get this functionality with an expensive, proprietary, and cumbersome J2EE server. Today we can do it with Apache and Tomcat. Thanks to the Tomcat developers and the open source model!

Graham King is senior software engineer for KBC Financial Products in London, where he builds Java Web applications in an agile team. Previously he built a content-monetizing framework in Java for Go Internet, and prior to that wrote lots of C. In his spare time, he volunteers with the Greenpeace I.T. team, and is an enthusiastic hiker.

Learn more about this topic

This story, "High availability Tomcat" was originally published by JavaWorld.

Related:

Copyright © 2004 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
How to choose a low-code development platform