Reading Time: 8 minutes

For those of you who are using Apache Tomcat in QA, staging, or production, I have no doubt that periodically you end up in the situation where you need to configure Tomcat’s server.xml, catalina.properties, logging.properties, and/or other Tomcat configuration files so that your webapps run the way you need them to run. Even though Tomcat allows us to configure the webapp’s <Context> in a separate file from server.xml, and even though Tomcat allows context.xml in the webapp’s META-INF directory that can be bundled as part of the webapp, that’s almost never enough to configure everything that the webapp needs. The <Context> tag by itself is just not self-contained to the point where you don’t also have to configure other important things in Tomcat’s server.xml to go along with your webapp’s <Context> configuration. To configure <Host>s, for example, we need to edit server.xml. For configuring connectors, such as enabling HTTPS, we need to edit server.xml. Even if you can configure your webapp’s database connection pool in your context.xml file, what about the JDBC driver JAR? You still have to manually copy that into CATALINA_HOME/lib, which is outside of your webapp in the Tomcat space.

If you need to configure these items in Tomcat’s configuration files, and if you happen to have several Tomcat servers to configure them in, then you’re either going to spend some significant time manually modifying each server’s config files, or you’re going to invent your own configuration file distribution process and scripts. Doing either of those is time consuming. This is where Tcat Server can help. Our new R2 release implements a way to centrally store and edit the necessary configuration files, called “server profiles”. Once you’ve prepared the configuration files, you can then publish the file set out to a group of Tomcat servers at the click of a single publish button.

Tcat Server 6's Edit Server Profile page

Here you see the Tcat Server 6 R2 Edit Server Profile page where we’ve created a file set of modified Tomcat configuration files and also the MySQL JDBC driver. This is the set of files required for a web application that uses the database and also needs special configuration for the host it serves from, custom connector configuration for HTTPS, etc. What’s more, it needs some environment variable settings as well to make internationalization work properly, and we want to specify which JDK it all runs on. We’ve captured all of that configuration in this “Production Web Servers” profile and stored it in the centralized Tcat Server console. From there, we can publish this custom Tomcat configuration out to a group of servers with a single button click.

This is very useful for a couple of different scenarios where you need to configure Tomcat’s files, Java startup switches, and/or environment variables:

  • Webapp deployment time initial configuration: When you first get a webapp running, you’ll need to configure Tomcat for it.
  • Ongoing operational adjustments: After you’ve been running the webapp for a while (including in QA, staging, and production), you may need to make some Tomcat configuration changes to improve how the webapp runs, or to correct a problem.

Another scenario where Tcat Server’s configuration management features can save you time is when you are tuning JVM memory parameters to fit your webapp’s memory utilization. When you run your web application in your staging or production cluster under some load, you’ll then find what the real memory utilization pattern is. Only then will you know best what JVM memory settings to use. You can see this at a glance using the Tcat Server console’s Memory Utilization graphs page.

Tcat Server 6's Memory Utilization page

Once you know some real utilization numbers, you can then change the JVM settings on each of your Tomcat servers. Without Tcat Server, you would need to edit the configuration files, possibly copying them into place on each server, then issue the restart command manually on each server machine. Again, using Tcat to make the change saves you time because you would just change the JVM startup switches in the JAVA_OPTS environment variable of the centralized server profile, then publish it to all of the servers. Once that is done, you can restart all of your Tomcat servers simultaneously, simply by performing a server group restart. At that point your servers are configured consistently across all server machines and are configured with values you know are correct for your traffic load, all done through Tcat’s central administration console. Tcat Server is an elegant and time-saving solution, combined with the open source Tomcat you already use.

latest report
Learn why we are the Leaders in API management and iPaaS