One of Pivotal’s field engineers, Dan Carwin, recently began a series of posts breaking down differences between Pivotal tc Server and Apache Tomcat. In this post, we outline the five key configuration differences that Dan reported on with more detail. The upcoming, second post will cover the second category of differences—extensions to functionality.
The five key differences in configuration with Apache Tomcat and tc Server:
Most importantly, tc Server has been designed to be completely interchangeable with Tomcat—you can run the same codebase on either one, and we provide a 100% compatibility guarantee. The tc Server engineering team includes Apache contributors, committers, and team members—we are part of the community and know that integrity here means that our version must be completely interchangeable. Since we have been supporting Tomcat since 2001 (version 3.x), we can stand by our word.
Anyone who wants to make configuration changes to the ASF's Tomcat can do so, and you might see that this list includes some of the same configuration changes that you have already done. Of course, we run into many people who aren’t aware of the options. Each of these five items helps take Tomcat to another level of enterprise readiness—together, they make it easier for admins, improve scale, and enhance security.
We set up tc Server so that one set of binaries can power multiple instances of tc Server—each instance has separate configuration and can operate independently in a modified directory structure. You can now patch or update without touching a config file. We also provide a script to create new instances or update existing ones—maintaining versions and patches across a farm is much easier this way.
If you didn’t know already, Tomcat can support variables in config files. In tc Server, an identical
server.xml file can be deployed to all instances in a farm or cluster with independent server settings. We set it up so that elements like ports and IP addresses are variables in
server.xml, and the independent values are stored in a separate file,
The default logging can impact high-volume applications—if the application has to wait for the file system or there is log file contention, it can degrade performance. With the asynchronous logging in tc Server, the application is configured to use a separate thread—not the one serving the user’s request.
Tomcat has proven to be really secure, and we don’t change anything radical. Yet, there are two configuration changes we make to improve security. First, the default shutdown port (8005) is disabled to avoid inadvertent and malicious shutdowns, and we provide a process-based method instead. Second, the Manager application is accessed via HTTP which is the same way users access applications. Typically, security experts like to keep these channels separate. While we include it as a convenience in developer editions, an extended JMX interface is provided instead for more secure deployments.
Often times, Apache Tomcat is paired with the Apache HTTPD web server, and one of the leading reasons is because the compiled C-code in Apache HTTPD is much faster at SSL encryption and decryption. Tomcat also provides a method for a portable version of the compiled C-code connector called TC-Native. With Tomcat, you may need to take extra steps to compile and assemble the connector. Instead, tc Server provides a pre-built version.
Again, anyone can make these adjustments, but, in our experience, they are typically overlooked. In part two of the series, we dtill into the extended functionality provided in tc Server. Stay tuned!