In most surveys, Apache Tomcat comes out on top as the most popular application server. It continues to run the majority of Java applications on Earth—what a great success for open software developers.
As a software engineer who spends most of his time working on Apache Tomcat and Pivotal tc Server, I wanted to share a no-fluff perspective on why development teams might consider using Pivotal tc Server which is derived from Apache Tomcat. In a nutshell, it is truly enterprise ready—we improve upon the default configuration and extend the functionality to make this lean server a better runtime for both developers and admins.
Our Background with Tomcat
If you look into the history of the companies that have merged into what is now Pivotal, you’ll see that we have been supporting ASF Tomcat since version 3.x. We’ve got unparalleled expertise on staff, the most aggressive SLAs in the industry, and a history of Tomcat support reaching back more than twelve years. We compile our own distribution tc Server that is derived from Apache Tomcat and also provide technical support, services and education for both products.
Why Mess with a Good Thing?
The answer is we don’t. Everything that is good in ASF Tomcat is still in tc Server—nothing is removed. Any Java application that runs on ASF Tomcat will run on tc Server without needing any modifications. Likewise, it means you can migrate off of tc Server if you want to—again with no code-level modifications. As you’ll see later, there are things you can do at the configuration-level to take advantage of some of tc Server’s extensions, but at the binary level we guarantee 100% compatibility.
ASF Community Contribution
Before launching into detail on tc Server extensions, let’s look at the work that Pivotal contributes to the ASF Tomcat project. Pivotal engineers have been committing code directly to Tomcat since 2001 and recently made several major contributions into the project such as parallel deployment for application (.war file) updates, high-concurrency database connection pooling, and advanced session replication. In addition to developing new features in Tomcat, Pivotal engineers are responsible for committing the vast majority of bug fixes. When we develop a feature that is relevant and acceptable to the Tomcat project, we contribute that code into Tomcat.
Security Team Members
Pivotal is also very fortunate to employ two members of the Apache Security Team, which means that our staff is aware of potential security vulnerabilities very early in the validation process. Knowledge of pending security issues enables Pivotal to make sure that our customers (including both open source Tomcat support and tc Server) are provided with fixes or workarounds immediately. For tc Server, we can roll a fix into a patch and make it available as a download to our customers and partners before the vulnerability is made public. This keeps our customers ahead of the curve.
Smart Configuration for Enterprise Deployment
When you look at how tc Server differs from Tomcat you’ll see that the differences can be grouped into two categories: configuration changes and extensions. This remainder of this blog posting will deal with the configuration changes, and part two will dive into the extensions.
Configuration changes are those things that anyone can do with standard ASF Tomcat. Looking down the list, you may see that your team makes some of the same configuration changes that we do. On the other hand, many Tomcat users are not aware of the possibilities and are pleasantly surprised that tc Server’s configuration makes their life easier by simplifying configuration, improving scale, or enhancing security.
Multi-instance Support with Shared Binaries
Tomcat comes from the ASF configured with one application deployment directory (/webapps), one configuration directory (/conf), and one set of Tomcat binaries corresponding to a given Tomcat version (/bin). In comparison, tc Server comes pre-configured to support the concept of a runtime instance, which separates the binaries (CATALINA_HOME) from the applications and their configuration (CATALINA_BASE). One set of binaries can now power multiple instances–these can be configured and operated independently. We provide a script to create new instances and update existing instances.
The approach provides some key benefits for administrators. It’s much easier to maintain a consistent Tomcat version and patch level across a farm of instances. Upgrading or downgrading Tomcat versions becomes trivial—just drop in the new set of binaries next to the existing set and invoke the instance script to point one or all of your instances to the new set of binaries. The binaries and the instances can also be stored in different locations.
Variable Substitution for Consistent Configuration and Port Management
A lesser-known native Tomcat feature is support for variable substitution in configuration files. tc Server uses this feature, making it easier to deploy and manage configuration consistently. Configuration values that need to be different from instance to instance, such as ports and IP addresses, are represented by variables within server.xml. The actual values are stored in a separate file, catalina.properties. This allows administrators to deploy an identical server.xml file to every tc Server instance in a cluster or farm, and they can now control configuration independently of addressing.
Asynchronous Logging
tc Server gives you a simple option for enabling asynchronous logging when you create a new instance. This is another valuable and native feature of Tomcat and is not enabled by default. Asynchronous logging is important in specific cases where you have a very high-volume application, and you want to ensure that the performance of your application is not affected by waiting for the logging process to write information to log files. The asynchronous logger uses a separate thread for logging (i.e. not the thread serving the user’s request). As well, it has a configurable memory buffer to hold log data in case there is a wait for the file system. With this option, applications are not slowed down by busy file systems or contention in the log files.
Security Tuning
tc Server does not do anything radical with regards to improving security in Tomcat. Tomcat has proven to be a very safe and secure server in its default Apache configuration, but there are a couple configuration changes we make that lock down tc Server a little tighter. First, we disable the default shutdown port. ASF Tomcat listens for shutdown commands by default on port 8005—anyone with local access to port 8005 on the server can shut down your Tomcat instance. tc Server disables the shutdown port to prevent inadvertent or malicious shutdowns, and uses process-based methods to shut down instances.
The Manager application is used in ASF Tomcat as a convenient way to deploy and control new applications, but it does so over HTTP, which is the same protocol used to access those applications. This can present security risks in production. Instead of providing the Manager Application, tc Server contains an extended JMX interface to allow secure application deployment. The Manager application is included in the free Developer Edition of tc Server as a convenience for devs.
TC-Native (compiled C) Connectors
Apache Tomcat is a pure Java application server, and it is common practice to pair Apache Tomcat with the Apache HTTPD web server. This can be done for many different reasons but one of the leading reasons is that the compiled C-code in Apache HTTPD is much faster at handling SSL encryption and decryption.
Since 2008, Tomcat has supported a method for using a portable portion of Apache HTTPD’s complied C-code (called the Apache Portable Runtime, or APR) as part of an input connector. This input connector is called TC-Native. TC-Native uses the compiled C-libraries in the APR for SSL functions. With the connector, Tomcat is much faster at handling SSL. However, you may need to compile the APR for yourself and then assemble it with OpenSSL into the TC-Native connector to use inside ASF Tomcat. With tc Server, customers don’t have to build their own connector—we provide a pre-built one.
To Be Continued…
As mentioned, the items above are mainly configuration changes that anyone can do with open-source Apache Tomcat code, but they often don’t. Please stay tuned for part two of this series where we will focus on the extended Pivotal functionality that is not found in ASF Tomcat.
