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.
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 29th (YEA!) and a large number of people have already downloaded that snapshot to evaluate (or beat on) it.
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 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!
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:
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.
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.
Additional Tomcat 7 Features. The fun with Tomcat 7 doesn’'t stop with the Servlet 3.0 specification support. Also included are are:
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.
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.