TomcatExpert

Interview with Mark Thomas, Apache Tomcat 7 Committer & Release Manager

posted by avanabs on August 2, 2010 07:57 AM

In my previous blog, I discussed the adoption of Tomcat 7 from the consultant/users view. I also promised an interview with one of the Apache Tomcat 7 committers, to provide the insiders views.

We’re here today with Mark Thomas, Apache Tomcat Committer and Release Manager for Tomcat 7.

Andy: Thanks for spending the time with me this evening. Congratulations to you and the Tomcat Community for achieving the Beta milestone for Release 7. We’re hearing interest from our clients, and it looks like there is lots of good stuff in this release.

 I understand that you are "Release Manager", as well as committer, for Tomcat 7...what does that role entail?

Mark: The Tomcat community has traditionally had a 'fixed' release manager for each major branch. It is fixed in that the same person does it for several releases in a row but in theory any committer could start a release at any point. As release manager, I build the release (do a clean checkout from svn and then 'ant release'), upload the release to a staging area and then call a vote on the dev list.

If the vote passes, I copy the files from the staging area to the distribution area, update the download links, update the latest version information on the Tomcat homepage, upload the maven artifacts and send out the release announcement to the lists. It sounds like a lot of work, but it is 99% automated.

Much more effort goes into the voting phase, where we check the release quality.

Andy:  One of the most frequent questions we are hearing is “Should I be planning to adopt Tomcat 7 for my application and if so, when”? Some people are advising that users wait (as much as a year or more) for “more stable” versions of Tomcat 7 before beginning adoption, but clearly the community (and release) also benefits from short term user experience…a classic “catch 22”. What do you think?

Mark:  I think it depends on the level of risk / severity of bugs you are prepared to accept and on which features you want to use. If you want rock solid stability, then stick with Tomcat 6.

If you are prepared for a few bugs, happy to upgrade to fix them and don't need Servlet 3.0 features, then Tomcat 7 could work. This would be OK in most development environments, but it would depend on when you plan to go live.

If you need Servlet 3.0 features then you have no choice but to use Tomcat 7. There were issues in 7.0.0. 7.0.1 will be better, but I wouldn't be surprised if there are more issues. You’d need to be prepared for regular upgrades.

It is hard to be definite in terms of timescales. The more folks that use Tomcat 7, the faster it will be stable but early adopters can expect to find bugs.

What I have been saying when asked is that it usually takes 6-12 months for a release to become stable (as in SpringSource will provide production support for it). That would put a stable release somewhere in the first half of 2011. The ASF normally declares a stable release a little earlier. My hope is that with more regular releases that we will hit stability earlier.

There have been lots of fixes since 7.0.0 so 7.0.1 is imminent. I think folks have to monitor the open bugs (http://s.apache.org/tomcat-7-open-issues) and the fixed issues (http://svn.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml) and decide for themselves when the time is right to switch.

I would hope a couple more releases and we'll be good to go for most developer environments - even the conservative ones - and production ready a few releases after that. But it all depends on the take-up.

Andy:  This breaks down into two use cases…upgrading existing applications and writing new applications. What would you advise end users to do in each case?

Mark:  Unfortunately, there is no easy answer regarding Tomcat 7 in production. I'd say it is too early, but if it is an in-house app and it works...

Andy:  How does the stability of Tomcat 7 release compare with prior versions, for example Tomcat 6 release?

Mark:  I think better. But that is very subjective.

To summarize: If I wanted to experiment with 3.0, I'd use Tomcat 7. If I was starting a new project where I'd be using Tomcat all the time, I'd be considering Tomcat 7 and would probably use it in development from the 7.0.1/7.0.2 release. Release 7.0.0 has way too many major bugs. For production, I would be watching the release notes very carefully and testing my application thoroughly.

It is almost too early to estimate which release will be the first production ready one. I hope it is early but until we get there...

I will say all the releases always pass all the unit tests and all the compatibility test suites (Servlet, JSP & EL)

Andy:  I’ve seen one Tomcat 7 application where testing at a client shows their app is about 8% faster (no idea why), on the same server. That app is highly instrumented and their stress testing is pretty through. What is your expectation regarding Tomcat 7’s performance?

Mark:  I know I cleaned out some crud, but I didn't think it was that much!

Andy:  IT organizations have experience with “dot-zero” releases of commercial products, much of it not very good. Are there differences between the Open Source development process and commercial software process that would affect the adoption decision.

Mark:  It might not affect the decision, but you certainly get a lot more information with which to make it. Want to know all the bugs we found and fixed in Tomcat 7.0.0? Easy. And that list is updated as we move towards Tomcat 7.0.1 so you know what has been fixed before the release.

You can also see the list of open/unfixed bugs. You have much more info to help you decide.

Andy:  Shifting gears a bit, you mentioned this above, but…Perhaps the most discussed feature in Tomcat 7 is support for the now released (Dec 10, 2009) Servlet 3.0 specification. Tomcat 6 has some of the features of Servlet 3 (for example async), but Tomcat 7 now implements the Servlet standard. Would this be an important driver for upgrading or for transitioning to Tomcat 7 for new projects?

Mark:  Certainly. If folks want to use the new Servlet 3.0 features then they'll need to upgrade. There does seem to be quite a bit of interest - at least folks are pointing out where things go wrong quite quickly.

Andy:  Many users are adopting Tomcat as the infrastructure for software frameworks, for example Spring and Grails. How does Tomcat 7 improve that use case?

Mark:  Marginally, compared to Tomcat 6. There are some hooks in Servlet 3.0 that make setting up a framework a little easier, but the frameworks aren't using them at the moment and even when they do, I don't think it will make a big difference.

I think you'll see a bigger change when the frameworks start to take advantage of Servlet 3.0 features.

Andy:  What about virtualization of Tomcat 7; VMware, Xen, Oracle VM, RedHat Virtualization, etc?

Mark:  I don't see Tomcat 7 being very different from Tomcat 6 in that respect.

Andy:  Tomcat 6 emerged as IT organizations were devolving their mega-blob applications into horizontally scaled, components/services, and Tomcat 6 was widely adopted as the infrastructure of choice due to its footprint, performance, and reliability More recently, IT organizations are shifting production deployments into virtualized servers, where Tomcat is again an infrastructure of choice. How does Tomcat 7 support today’s deployment architectures and what are the improvements that would motivate upgrading?

Mark:  The small footprint, ease of install and low cost remain the driving reasons for using Tomcat. New features typically get added to just the latest release so access to those new features - like the memory leak protection and prevention - is one of the drivers to upgrade.

Some of those can get back -ported to earlier releases but usually not all of them and not as quickly.

Andy:  One interesting feature is enabling Tomcat 7 to reduce/eliminate application memory leaks. Can you tell us a bit more about what led to that functionality being included and what it actually does? Also, would this be a motivator for upgrading, either for production or for new development?

Mark: I was speaking at a Java conference and said words to the effect of "PermGen memory leaks on application reload are triggered by application bugs, not Tomcat bugs" to a few hundred java developers, many of whom challenged that statement. As a result I spend the next day or so debugging various applications and we found that whilst it wasn't Tomcat causing the leaks, it wasn't always the applications either. There were issues with various parts of the standard Java API. I quickly spotted I could provide workarounds for some of these and that is what started this work. I then took a couple of other apps (Spring sample apps) found more root causes of leaks and added fixes for those. Other community members became interested and contributed their own ideas and the end result is what we have today along with a bunch of cool ideas for making it even better.

Andy:  I remember your presentation well, and the fairly strong reaction of the folks sitting near me. I know applications that get auto booted every night, because of out of memory problems. So, how about the "motivator for upgrading either for production or for new development" part of the question?

Mark:  Absolutely. A lot of the new ideas for memory leak prevention and detection might not make it to Tomcat 6.0.x (some haven't already).

Andy:  What are the three most compelling new features in the Tomcat 7 release that would influence users to upgrade?

Mark:  Servlet 3.0, memory leak prevention and detection, and improved security.

Andy:  And, what are the three biggest barriers to upgrading in the short term?

Mark:  1. General instability triggered by various internal refactorings (should be resolved pretty quickly)

2. Instability in the Servlet 3.0 implementation. May take a little longer

3. Changes between 6 and 7 that impact the application - see http://tomcat.apache.org/migration.html (should be relatively few)

Andy:  Mark, thanks very much for your valuable time and expertise. Anything else you’d like to add?

Mark:  Just the usual, if folks would like to get involved in Tomcat 7 development, they are always welcome on the dev list dev@tomcat.apache.org.

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).

Comments

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.