Is Apache Tomcat 7 in your future?

posted by avanabs on July 29, 2010 07:26 AM

I’ve been following Tomcat 7 development for some time now and I've been asked recently why (and when) clients should upgrade to Tomcat 7, now that it’s nearing release (currently targeted for “late summer”). So, I’ve started to give some thought to that question. I have to admit, the answer wasn’t immediately obvious either way. I’m going to split this blog into two parts; the first with my views and very preliminary results of my testing and evaluation. The second will be based on an interview scheduled for this Wednesday with one of the senior Apache Tomcat “committers”.

Note: In Apache Speak, a Committer is selected by his peers to be trusted to make changes to the code base. In a mature and extremely widely used project like Tomcat, this is very hard to achieve and carries great responsibility.

When I think about “upgrading”, I immediately think about two quite different scenarios.

1. Upgrading existing infrastructure for production environments. “If it works, why mess with it?” surely applies.
2. Selecting the infrastructure for new projects. “Should I really base my critical new project on a dot-zero infrastructure release?” is usually my first thought.

We’ll explore both situations, focusing on both Tomcat 7’s stability as a “dot-zero” release and what new capabilities Tomcat 7 brings to the table.

Tomcat 7 is the first major Tomcat release in quite a long while (three and a half years…and counting), since Dec 1, 2006 when Tomcat 6.0 was released. Tomcat 7 Beta was released on June 29^th (YEA!) and a large number of people have already downloaded that snapshot to evaluate (or beat on) it.

Stability

Let’s first talk about stability. I believe that it’s important to consider the differences between conventional commercial software products (where I wouldn’t take a dot-zero into production for anything, and I am often reluctant to even try it out) and Open Source, where I assert the situation can be very different. A major difference between these is in development/testing methodology.

Commercial Software

Commercial software is thoroughly tested by QA organizations during development and as the release draws to closure. Tests are a performed by a combination of automation for repetitive tasks and manual for things rapidly changing and/or too difficult to automate. Tests are written by QA Engineers and are (almost always) designed to prove the feature does what’s its spec says it should do. Only rarely is there sufficient budget/time (or inclination) to indulge in the opposite, which is to try all the things it shouldn’t do, or in other words: to trash it. That also requires a particular mentality, all too rare in QA organizations. Corporate pressure is “make sure it works”, not “try to prove it doesn’t work”. There is also little/no "use case" testing, particularly for infrastructure products, due to the difficulty of creating or obtaining sufficiently broad and complex use cases.

At some point in time the software is deemed “Beta” and released, typically to a very small number of carefully selected and closely managed accounts. Almost always, this process is driven by Marketing/Sales, and in many cases Beta is actually managed by them. In my experience running software products and software development organizations, I’ve rarely seen anything come out of Beta testing that benefitted the product…that’s not what the Beta process was really being used for.

So, commercial software products ship with extensive “prove the features work” testing and virtually no “prove the product solves the customers business problems” testing. Sad, but true. The result is a dot-zero release has had almost no actual use when it hits the street. So, we avoid it at all cost, particularly if we value our jobs!

Open Source Software

In sharp contrast, Open Source projects are available to whomever wants to grab them and beat on them, through virtually the entire development cycle. Nowhere is there a contact that says “you can have this, play with it a bit so we can claim we’re getting close, but you absolutely positively MUST NOT try to really use it”. I’ve seen Open Source projects successfully find their way into production, and even into commercial products, well before they ever “get released”. This is a valuable part of the hardening process and it’s up to the users to determine their level of risk…not a vendor.

There are also those engineers that take great delight in finding and exposing flaws in their peers work, whether through breaking it functionally or through exhaustive code review/analysis. This also is a valuable (though it can be hard on the ego…I still remember a submission I did to a OS project a number of years ago, which got loudly...and publically trashed) part of the hardening process and I’ve never seen that behavior allowed, much less encouraged, in a commercial environment.

Finally, only in OpenSource does the user have access to the entire release defect log, bugs found, bugs fixed, and even the source code to do their own use case debugging.

So, an active Open Source project has been subject to:

1. An extended period of real world “use case testing”, without artificial bounds
2. Some (typically less than a commercial product) “does the feature work” testing
3. A large number of smart eyes, many of whom are looking for a better way to do things and some of whom take great delight in breaking things by subjecting them to abuse that’s way beyond that found in the real world.

For these reasons, my experience with dot-zero (and closely following) releases of mature Open Source projects has been very different than it with commercial products…either mine or others. I’m much more confident that open source projects have been subject to review (torture?), beyond anything I might do (I still do my own testing, of course) and that a community of very smart people has exercised due diligence for their own purposes.

So, I’d make the claim that I NEVER take/recommend a dot-zero for a commercial infrastructure product and I FREQUENTLY take/recommend a dot-zero or dot-zero + release of a mature Open Source infrastructure product.

In the case of Tomcat 7, if the new features offer me benefit for my new project, I’d be inclined to use it and move forward, although with due caution and the understanding that I'm participating in a community hardening effort. For my current production environments, I’d be somewhat more cautious, although I could make the case to upgrade if it was sufficiently easy to do so (more about that later) and if I saw significant benefit from the new capabilities for my old application. In both cases, I wouldn’t let fear of dot-zero-itis control my decision.

Note: My (limited) experience to date is that Tomcat 7 is at least as stable as the Tomcat 6 versions that I’ve been building applications on for a number of years. That said, I've only experienced one production use and two test cases, so this is VERY preliminary.

Functionality

As I noted above, Tomcat 7 has lots to like. This includes, but is certainly not limited to, full support for the Java Servlet 3.0, JSP 2.2, and EL 2.2 specifications. TC 7 makes it even easier to create ever more complex web applications, including lots of bundled features that we’d have to implement or find third party solutions for. It also improves Tomcat’s already impressive performance and efficiency, which is particularly important in today’s distributed service (and increasingly virtualized) deployment architectures.

Another area that I’m excited about is Tomcat 7’s improved memory leak prevention/detection. Many developers tend to blame Tomcat for their application memory leaks, partly because Tomcat did have some issues in its early days and developer memories are very long and partially because Tomcat did very little to enforce or detect memory leakage in the client code. Basically you had to check server logging, which is FAR more difficult in horizontally scaled, services based, virtualized, deployments…perhaps even impossible.

Many of my clients also pair Tomcat with SpringSource, creating a “SpringSource Server” that is both performant and reliable. TC 7 makes Tomcat an even better platform for frameworks such as Spring.

Servlet 3.0. Servlet 3.0 improves ease of development, extensibility, and security. It also adds support for asynchronous programming techniques.

• Asynchronous Support. Servlet 3.0's asynchronous support has been fully implemented in TC 7. There was async programming in Tomcat 6, but Servlet 3.0 support offers developers a standard interface, improving portability between containers.
• Dynamic Configuration. Another Servlet 3.0-related feature is Tomcat 7's dynamic configuration functionality. Tomcat 7 provides support for web fragments, so libraries can use an embedded web.xml fragment for configuration, eliminating the need to add library-specific configuration entries to application's web.xml files.
• Annotation Support. Tomcat 7 also includes Servlet 3.0's new annotation support, offering developers a way to configure filters, listeners, and servlets using declarative style programming. Classes and servlets can be quickly defined by annotating the class, which makes development faster and eliminates the need for deployment descriptors.
• Extended Servlet API. An extension of the Servlet API enables the programmatic addition of Filters and Servlets when an application starts. Although access to this API while running an application is prohibited in the Servlet 3.0 specification, Tomcat 7 will allow developers to ignore this somewhat controversial limitation if they wish, at the expense of portability.
•  More Servlet 3.0 Features. Other features that developers will appreciate include the use of generics, improved session tracking and SSL session ID tracking for increased security. Also included is a brand new file upload functionality, which will allow developers to upload additional libraries as needed.

Additional Tomcat 7 Features. The fun with Tomcat 7 doesn’'t stop with the Servlet 3.0 specification support. Also included are are:

•  Simplified Embedding. Tomcat 7 includes an API that makes embeddable Tomcat applications a simple, hassle-free reality. Utilizing this new API, developers only need a few lines of code to get Tomcat running within their applications.
•  Improved Logging. Tomcat 7 includes two improvements to its logging system: a single line log formatter to make log files easier to read and an asynchronous file handler. The single line formatter writes logs in a single line, which makes life much easier for IT admins. The asynchronous handler allows Tomcat to write logs to disk in a dedicated thread, so that logging operations do not cause any latency in processing threads.
•  Aliases. This new feature allows inclusion of external file systems or Web Application Archive content within an application, such as images or JavaScript directories, so that shared assets can be centrally distributed across a wide array of web applications. In today’s deployment architectures, this is hugely powerful.
•  Memory Leak Detection/Prevention. Although the bugs in Tomcat's 4.1.x/5.5.x codebase responsible for some of these errors have long been fixed, developers still had trouble eliminating memory leaks caused by their own applications. Tomcat users have historically had problems with memory leaks when reloading web applications throughout the existence of the project, usually manifesting as an OutOfMemoryError for the Permanent Generation. The Tomcat team has been frustrated from time to time by applications that continue to adversely affect perceptions of Tomcat’s reliability. So, they decided to enhance Tomcat to be able to deal with many of the application defects that caused memory leaks. They were able to track down and repair a number of bugs specific to certain Java APIs and they wrote patches for the most common application-caused memory leaks. Applications which previously triggered these leaks can now reload without error and new applications will be covered as well.
•  Improved Security. The Manager and host-manager applications have been made more secure, by splitting privileges into multiple roles. Tomcat 7 also includes blocking to prevent tampering with the Session ID (sometimes called session fixation attacks). There are also now separate roles for script-based, web-based, JMX proxy, and status page access, for more specific access control.

Upgrading

As I noted above, I’ve been playing with Tomcat 7 for some time. I’ve also tried moving a few applications from Tomcat 6. I didn’t avail myself of Servlet 3.0, so my experience so far is more of a “upgrade existing application” rather than “develop new application” scenario. See http://tomcat.apache.org/migration.html for help when you start this process and also see Mark Thomas’s blog for some additional info.

•  OS/Environment. I ran the Tomcat 7 upgrades on RHEL 5 and Java 6. I had some difficulty building Tomcat 7, but I never really figured out why. Suddenly, it just worked, so it may have been pilot error.
•  Tomcat Manager. I personally find Tomcat Manager more trouble than not. I really prefer the commercial management products (such as vmWare/SpringSource and MuleSource, although for very different reasons). That said, I did muddle thru the Tomcat 7 Manager just to see what I thought. The biggest change I found in manager is that manager has been split into multiple console segments, each with its own URL (enabling more detailed privilege management). These are the Web Interface, the Text Interface, the JMSProxy/Servlet, and the Server Status page(s). Each now also has a specific Manager Role associated with it and host manager has likewise been split into multiple roles. This should improve management security, although no where near as much as the aforementioned products.
•  Deployment. This is one of the bigger changes in administration, because the most commonly used deployment—context descriptors contained in WAR files were extracted and deployed into the containing Host's xmlBase— is no longer the default behavior. You can apparently re-enable this if you wish, but for the purpose of the experiments, I did not.
•  Application Behavior. Porting these three applications to Tomcat 7 was pretty straightforward. In the first case, the application “just worked” once I got it deployed and in the second case, I needed to do some tweaking of the configuration. In the last case, I needed to do some recoding because of the use of Hibernate. I haven’t ported any Spring Based applications, but I expect those will go similarly easily…and probably better where additional services such as data persistence are utilized.
•  Application Performance/Reliability. I’ve not done any stress testing yet, but my first impressions are that the applications are at least as stable and just a touch faster. One of the applications—that happens to be well instrumented— runs about 8% faster with Tomcat 7.

Conclusion

Would I use Tomcat 7 for a new mission critical application? Possibly, depending mainly on the benefits of Servlet 3.0 and the schdule for the application release and I might wait for a point release or two. Would I upgrade existing running applications to Tomcat 7? Not yet, unless there were compelling functional reasons to take that risk. Once again, it would depend somewhat on the schedule. Of course, if my existing application had problems (for example, having to be re-started every few weeks because it ran out of resources), then I would at least try Tomcat 7 to see if it caught my application problem.

I’d be very interested in hearing about your experiences and hear your thoughts.

Andy has recently decided to make the jump from individual consulting to join the Spring Source team. He will continue to be working with major clients to assist them with IT architecture evolution, now as a member of a large and growing organization. His first project will be leveraging Tomcat, Spring, and a Tomcat based data grid/cache called GemFire. He’s looking forward to sharing the lessons learned with the tomcatexpert community. Andy has been architecting, designing, and building enterprise infrastructure and applications software for most of his career. He’s been responsible for BEA’s “Blended Source” initiative, combining the best of Open Source (including both Tomcat and Spring) with WebLogic, BEA’s WebLogic Enterprise Security product family, MEI Software’s financial systems, Netegrity’s SiteMinder security product, Camex’s electronic publishing systems, mainframe applications for Bell Telephone, and many others. During that time his hands on technology experience has ranged from octal coding into neon lighted switches all the way through JAVA and beyond, including many generations of “the best and final thing we will ever need”, and he looks forward to working on the even better things coming in the future. He was involved in the early days of Open Source software as a contributor to EMACS and refocused on Open Source during his tenure as Director of Product Management with BEA Systems, combined with a fascination for the rapidly evolving application deployment architectures and technologies driving today’s development. Andy has provided architecture and technology guidance for both vendors and IT organizations and he shares what he is learning through consulting services and through his web site, Enterprise Software Trends (www.estrends.com).