With special thanks to Mark Thomas, ASF/VMware for reviewing.
This document will describe all of the necessary pre-requisites to get started in developing, customizing and contributing to the Apache Tomcat Project. The reader will have a broad overview of what is involved, and learn the process by which they will get a better understand of how the internals of how the Apache Tomcat application server works. Those new to the Apache Tomcat project, or contributing to an open source project may find this article helpful.
Apache Tomcat is the de-facto, open-source application server. It is distributed under the Apache License, Version 2.0 and is true open source. Many organizations use Tomcat as their production's application server, and it is enterprise grade even in its open source form. Over half of Fortune 500 companies use Apache Tomcat as their platform for their production business websites, including notables such as E-Trade.com, Walmart.com, and The Weather Channel. There are commercially supported versions of Apache Tomcat as well. In this how-to article, we will use the open source version as an example.
Often times a developer or operations professional needs access to monitor a Tomcat instance for purposes of capacity planning, troubleshooting, and performance tuning. There are many tools available already for Tomcat, some of them open source, and others paid for. Some tools are simple and others are complex management suites.
There are comprehensive monitoring suites available that monitor and manage Tomcat, and do it well; however, there is always a benefit to being able to create your own custom Tomcat/application management tools. The first advantage is that you get exactly what you want out of your utility. In my example, I wanted to have a way to browse a Tomcat server’s Java Management Extensions’ MBeans with a hierarchical, bash-like navigation. This allows me to quickly find and diagnose problems with my Tomcat server or custom applications running within Tomcat, and is more precise than trending those MBeans over time using a more comprehensive monitoring suite. I liken it to purchasing a ready-made suit, or having one custom tailored to your exact specification. It just feels better sometimes, and other times it is not practical.
Many utilities will not provide the specific feature that you need. There are usually a host of open source or commercial utilities for anything that one goal any developer or operations professional may want to achieve; however, often times that utility will not integrate well into their existing infrastructure, or not play well with automated processes that are pre-existing in the enterprise. In such cases, a custom utility can come in handy. Writing your own tools from scratch is a quick solution to a specific problem, and cuts out a lot of the fat. For simple tools, the complexity risk argument just isn't there, and in the time it takes to write a simple custom application.
There are three schools of thought on how to achieve the same task of managing a large production Tomcat infrastructure: distributed command-line solutions, custom tools using Java Management Extensions (JMX), and full-blown commercial software suites designed for managing Tomcat specifically. All of the methods and utilities for managing Tomcat have their own respective tradeoffs of elegance, simplicity, manageability, and cost.
The Tomcat Manager application is an excellent utility for managing Tomcat server. It has built-in support for deploying and un-deploying applications, reloading applications, gathering statistics about the JVM and Web application, as well as starting and stopping applications. IT even includes a Web-based JMX proxy where a user can modify and query MBeans through the manager application.
Where it falls short is that it primarily only supports functions for performing management operations at the servlet container level and above. It doesn’t allow a user to restart, start or stop the JVM that the Tomcat instance runs on from this Web interface and doesn’t have a built-in method for managing groups of Tomcat servers.
The simplest method is using ssh-keys and shell/Python/Ruby/Groovy scripts, which requires little effort to implement, but lacks in elegance. There are a number of service wrappers that support automatic restarts on failure, schedule restarts and taking thread dumps on failure, but they don’t come with a good interface through being managed remotely by a Java standard such as JMX.
Many institutions implement homegrown or scripted solutions for managing large Tomcat infrastructures. When dealing with anything beyond 10 Tomcat servers, it becomes tedious to log into each host and start and stop each Tomcat instance.
Many solutions exist for running a distributed command against a large group of Tomcat clusters. Some organizations set up SSH keys on all hosts and use a scripted or CGI Web interface to send a single command to a large group of servers; however, when dealing with thousands of hosts, installing the keys can become a tedious task, and without a configuration management utility, such as Puppet or Cfengine this can consume a large amount of time to perform.
Popular Links