The Apache Tomcat team announces the immediate availability of Apache Tomcat 7.0.40.
Apache Tomcat is an open source software implementation of the Java Servlet, JavaServer Pages and Java Expression Language technologies.
This release contains a security fix and a number of bug fixes and improvements compared to version 7.0.39. The notable changes include:
It is late on a Friday afternoon, and your web application has stopped responding to requests. The server is still reachable, and the Apache Tomcat process is still running–there are no errors in the logs. You want to go home but you can’t until it is fixed. What do you do?
If your answer is “restart Tomcat and hope it stays up until Monday,” then this article is for you.
Rather than keeping your fingers crossed and hoping you don’t get an angry call from your boss over the weekend, this article will provide you with some simple steps you can take to diagnose the problem.
If the Tomcat process is running, then it must be doing something. The question is what is it doing when it should be responding to requests? The way to answer that question is with a thread dump–actually, a series of thread dumps. You need to take three thread dumps roughly 10 seconds apart and then compare them. I always compare them with a diff tool rather than by eye—a it is far too easy to miss subtle but important differences between the dumps.
How you generate a thread dump depends on your operating system and how you are running Tomcat. On Linux, FreeBSD, Solaris etc. use kill -3 to trigger a thread dump. On Windows use CTRL-BREAK if Tomcat is running in a console window. If Tomcat is running as a service, then the service wrapper should provide a way to trigger a thread dump. Commons Daemon (the service wrapper that ships with Tomcat) provides an option to trigger a thread dump via the system tray icon.
ApacheCon North America is almost concluding, and my experience this year has not disappointed. It’s been great to be able to meet up with lots of other project committers. Many committers make the trek to ApacheCon wherever it is in the world and, given that we normally work together just via the project mailing lists, it has been great to be able to discuss current issues and new ideas face to face. Of course, all of these discussions will be making their way (if they aren't there already) to the Tomcat dev mailing list so the everyone in the community can participate.
Personally, I have spent a great deal of my time in presentations. I have spoken about progress on Tomcat 8, delivered another session on clustering and two on security covering vulnerabilities and security response at the ASF. As always, slides are available from http://people.apache.org/~markt and there should be video and audio recordings available as well at some point. Most sessions were reasonably well attended and the conversation and questions flowed after the presentations. Here are some of the questions and answers I found most interesting:
There has been some discussion on various forums and mailing lists about the End of Life for Java 6 and what it means for Apache Tomcat users. In response to these questions, we have put together this article that aims to summarize the key questions and give you some of the background and answers you need to plan how to best handle this transition in your deployments.
Here is a quick summary: If you want to run a supported version of Java—one with updates for bugs and security issues—then you will need to upgrade to Java 7. If this isn’t an option, you will have to purchase some form of support contract. Generally, upgrading to Java 7 will be the better long term option but the right decision for your business will depend on your circumstances.
For every Tomcat release, the formal build and testing is performed on the latest release of the minimum Java version required by the relevant specification. That means that the Tomcat 6 releases are built and tested with the latest Java 5 update and that the Tomcat 7 releases are built with the latest Java 6 update. There are also several continuous integration systems building and testing Tomcat with a variety of Java versions as well as all the local testing that the committers perform. In addition to all of this testing, the Apache Software Foundation (ASF) runs a number of services on Apache Tomcat—again using a variety of Java versions including the ASF Jira instance that runs on Java 7 and Tomcat 7. While I can recall several issues with running Tomcat on older, unsupported Java versions, I cannot recall a single reported problem that was traced to running Tomcat on a newer version of Java. Running Tomcat 6 or Tomcat 7 on Java 7 is very low risk.
Every effort is made to have each version of Apache Tomcat to ship with a system of reasonable defaults forsecurity purposes. This means that the standard defaults for the security settings are reasonably secure—it is not as secure as it could be, but not horribly insecure either. The default security level is essentially a compromise between security and usability. It is probably OK for simple use in production, but there are a number of things that all users should consider before deploying business applications on a standard installation of Apache Tomcat.
The Servlet 3 specification - implemented in Apache Tomcat 7 - allows web.xml fragments and annotations to be used to specify configuration information for a web application. This means that, instead of packaging up every configuration centrally in your web.xml file, every JAR can have its own xml fragment containing its own little bit of configuration for whatever classes are in that JAR. This makes it easy to add support for packages with very little effort. For instance, a Spring developer would no longer need to add the Spring application context to the web.xml file, rather they could take advantage of a web fragment in the Spring JAR that would automatically add this configuration information at runtime.
Annotations take this one step further, and allow developers to annotate code that dynamically configures application components such as Servlets and Filters. Java libraries and frameworks have been embracing annotations for some time. In fact, several IDE’s these days use annotations as a default, adding the @WebServlet annotation by default when you create a new Servlet in a dynamic web project.
Both annotations and web fragments will impact performance, particularly at application startup. Tomcat has to scan every class in every single jar file to detect if the class has been annotated as a Servlet, a Filter or Listener. This can add substantial time to application start up, which is not so much of a problem for production applications as they should start very infrequently, but it can be pretty problematic during development when you are repetitively restarting.
Tip: If you are not going to be using annotations or web-fragments, you should set your metadata-complete to true in your web.xml file to avoid the longer start up time. (
Java 7 has recently been released, and Apache Tomcat 8 project has just opened for development. It begs the question – are they related?
In short, not necessarily. We create a new major version of Tomcat when there are new versions of three specifications—Servlet, JavaServer Pages (JSP) and Expression Language (EL). Minor updates (maintenance releases) do sometimes get produced but major changes to all three specifications are released together as part of the J2EE specification. Once a new version of the J2EE specification is released, this is what governs the update to the next major version of Apache Tomcat, and it will implement the new features defined within these specifications.
For Tomcat 6, the defining specifications are the Servlet 2.5; JSP 2.1 and EL 2.1 specifications and for Tomcat 7 they are Servlet 3.0; JSP 2.2 and EL 2.2. Work on the Servlet 3.1 and EL 3.0 specifications is underway, and it is expected that there will be a new version of the JSP specification although I haven't seen any indication of work in that area yet. If the changes in JSP 2.2 are anything to go by, any changes in the JSP specification are likely to be minimal and will probably happen closer to the J2EE release. In terms of Java 7 support, Tomcat 8 will require the minimum Java version specified by the Servlet 3.1 specification. At the moment, I expect that that will be Java 7 but we won't know for sure until the specification is finalized.
As the work on the specifications proceeds (I am on the expert group for both Servlet 3.1 and EL 3.0) and the changes firm up then those changes will be implemented in the Tomcat 8 branch. So far, Tomcat 8 specific changes have been limited to re-factorings that change some of the internal APIs and therefore have not been back-ported to Tomcat 7 since we don't want to change APIs there unless we have to. Current ideas for what features (other than the specification changes) might be included in Tomcat 8 can be found in svn along with the Tomcat 8 specific changes so far.
Apache Tomcat 7 contains a number of new features around database connection pooling, which help administrators keep their application available and serving content, collecting customer information, and supporting their applications. The main one that has garnered a lot of attention is the new JDBC Connection Pool feature introduced by Filip Hanik last year. Another connection pool attribute not yet discussed here on TomcatExpert.com is the new closeMethod for speeding up the closing of JNDI resources that would otherwise be closed during garbage collection.
This feature stemmed from a common challenge for applications that make use of database connection pools attached to databases with limited connections allowed. For instance, if a database allows 50 connections, and an application uses a connection pool of 50 connections, in theory everything should work. However, if the application is reloaded, the existing open connections in the old pool would not close until they have been garbage collected. So the new application connection pool while configured for 50 connections, could run out at 37 if the old connection pool had 13 connections open.
As a VMware engineer dedicated to building Apache Tomcat and vFabric tc Server , I get the opportunity to see a lot of issues across the official Apache Tomcat public mailing lists, as well as VMware’s private professional support queue for both Apache Tomcat and tc Server. Typical of any software issue tracker, many of the issues logged could be avoided with a little better understanding of the Tomcat applications. Here are a few tips that may be useful to keep in mind:
There are two different types of context.xml files: one is global, and the other is specific to each web application. The problem with editing the global
context.xml file is, as its name implies, that it affects every web application running on that Tomcat instance. So for instance, if you have 10 web applications, and create a new JNDI datasource with 50 connections to the database in the global
context.xml file, you have essentially created 10 JNDI datasources with a total of 500 connections to your database and have likely completely overwhelmed your database. If you want to add a datasource to a single application, by remembering to create the datasource in the application level
context.xml file, you can avoid serious performance problems.
Occasionally companies will deploy 3 or 4 related applications on a Tomcat server that are designed to share a single datasource. As described above, placing the datasource definition either once in the global context.xml file or in 3 or 4 application specific
context.xml files will always create multiple instances of that datasource. To truly share a single datasource, it is necessary to put the definition of the datasource into the server.xml file, and then place a single resource link into the global
context.xml file. This link ensures only one instance of the datasource is ever created and when any application goes to use it, it always uses the same single instance.
Apache Tomcat 7 includes several security updates that further harden the application server that came directly from the Bugzilla queue. One new feature, the Security Lifecycle Listener, helps ensure that Tomcat is started in a reasonably secure way.
One user cited that while all administrators worth their salt should know that it is irresponsible and incredibly insecure to run Tomcat as the root user to the system, Tomcat still allows the server to start under root. Although this problem is largely contained to Linux systems, the fix had to be applicable to all operating systems. Therefore, the fix that was implemented was to create a list of users that are not allowed to start Tomcat. Tomcat checks to see if it is running as one of those users, and if it is, it shuts itself down.
A secondary check after the user is validated as a secure user, is to check that any files written by Tomcat (such the contents of an expanded WAR) are created securely. As a minimum, these files must not be world writeable. In some environments it may be desirable to restrict this even further such as read/write for owner, no access for anyone else. The permissions for created files are controlled by the current user's umask. If the umask is not restrictive enough on the running user, this too will prevent Tomcat from starting.