The Apache Tomcat team announces the immediate availability of Apache Tomcat 7.0.23
This release includes numerous bug fixes and several new features compared to version 7.0.22. The notable new features include:
Please refer to the change log for the complete list of changes:
This article is the second in a series discussing how to performance tune the JVM to better run Apache Tomcat. In the first article, we discussed the basic basic goals and how to monitor the performance of your JVM.
If you have not read the first article, I would strongly suggest reading that before continuing with this article. It is important to understand and follow the processes outlined in that article when performance tuning. They will both save you time and prevent you getting into trouble. With that, let's continue.
At this point we've covered the basics and are ready to begin examining the JVM options that are available to us. Please note that while these options can be used for any application running on the JVM, this article will focus sole only how they can be applied to Tomcat. The usage of these options for other applications may or may not be appropriate.
Note: For simplicity, it is assumed that you are running an Oracle Hotspot JVM.
Have you ever seen this scenario before? A user has deployed an application to a Tomcat server. The application works great during testing and QA; however, when the user moves the application into production, the load increases and Tomcat stops handling requests. At first this happens occasionally and for only 5 or 10 seconds per occurrence. It's such a small issue, the user might not even notice or, if noticed, may choose to just ignore the problem. After all, it's only 5 or 10 seconds and it's not happening very often. Unfortunately for the user, as the application continues to run the problem continues to occur and with a greater frequency; possibly until the Tomcat server just stops responding to requests all together.
There is a good chance that at some point in your career, you or someone you know has faced this issue. While there are multiple possible causes to this problem like blocked threads, too much load on the server, or even application specific problems, the one cause of this problem that I see over and over is excessive garbage collection.
As an application runs it creates objects. As it continues to run, many of these objects are no longer needed. In Java, the unused objects remain in memory until a garbage collection occurs and frees up the memory used by the objects. In most cases, these garbage collections run very quickly, but occasionally the garbage collector will need to run a “full” collection. When a full collection is run, not only does it take a considerable amount of time, but the entire JVM has to be paused while the collector runs. It is this “stop-the-world” behavior that causes Tomcat to fail to respond to a request.
Fortunately, there are some strategies which can be employed to mitigate the affects of garbage collections; but first, a quick discussion about performance tuning.
Valves have been an integral feature of Apache Tomcat since version 4 was introduced over seven years ago. As their name suggests, valves provide a way of inserting functionality within a pipeline, in this case, the Tomcat request / response stream. One simply writes a subclass of
org.apache.catalina.valves.ValveBase or a class that implements the
org.apache.catalina.valves.Valve interface and then adds an XML element with the valve’s classname to the appropriate configuration file (in most classes as a sub element of Engine in server.xml). Then, at some point (we’ll come back to that) in the processing of a request, your valve’s invoke method will be called. The invoke method gets passed both the Request and the Response objects, and is free to do whatever it likes with them (though having the power doesn’t mean it’s a good idea to use it).
You may be familiar with this paradigm through servlet filters used by web applications to do application-specific processing of the request / response pipeline. The key distinction between servlet filters and Tomcat Valves is that Valves are applied and controlled through the configuration of the application server. Depending on the container definition where the Valve element appears in the Tomcat configuration, the valve could be configured for all applications on the application server, a subset of applications, or even a single application (by locating the Valve element within a given Context).
This is a simple powerful model that has been written about extensively. A Google search on “tomcat valve” turns up a multitude of descriptions, examples, and “how tos”. The Reference Page on “The Valve Component” that ships with Apache Tomcat 7 documents the mechanism thoroughly along with descriptions of the valve implementations that ship by default. So why yet another article on the subject? What do I hope to add to the canon?
The effort started simply enough: The plan was to demonstrate the configuration and use of the
ThreadDiagnosticsValve that ships with VMware’s vFabric tc Server, a commercial application server based on Apache Tomcat. Additionally I would write and configure a custom Valve, in this case, a valve to exercise tc Server’s
ThreadDiagnosticsValve so that I could demonstrate its use and effects without actually having to have a misbehaving application to trigger it. Not exactly Nobel material, but I thought it would be a useful adjunct to the existing documentation and an interesting exercise.
However, it didn’t go exactly as planned and looking at the reason it didn’t is probably as helpful in understanding Tomcat Valves as the original exercise.
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.
I think the question sums it. I'm asked to design a server for an application that will be accessed by users. It's not a web application but i thought of using Tomcat and accessing it using HTTP to let Tomcat handle the threading.
My application might be used by ~10 000 users at the same time.
The handling of the request is fairly simple, it has access to a db but nothing heavy.
So do you thing Tomcat is well suited for this ?
Thank you for your help.
This is a very difficult question to answer because of the limited amount of information and the broad scope of the question. Given the information presented, here is what I can tell you.
In regards to...
It's not a web application but i thought of using Tomcat and accessing it using HTTP to let Tomcat handle the threading.
In general, this can be a good idea. Why reinvent the wheel? If you can reuse the capabilities of Tomcat (or another existing server) it should save you time and result in a better end result.
The only reason I would recommend against this is if the server that you are trying to build does not match up well with Tomcat or with the HTTP protocol.
Ultimately, it is up to you to analyze the usage patterns of the application to see if using Tomcat & HTTP will work for your application.
In regards to...
My application might be used by ~10 000 users at the same time. The handling of the request is fairly simple, it has access to a db but nothing heavy.
The real question here is not can Tomcat handle this traffic, but can your application handle this level of traffic. The majority of the time spent processing any request is spent in the application itself (processing business logic, accessing databases, etc...) and not in Tomcat. Because of this, it is very important to monitor and load test the performance of your application as you develop it.
Additionally, it's going to be important that your application is written to scale. It is possible to run multiple Tomcat instance in a cluster such that requests can be distributed across all of the instances. If you develop your application so that it takes advantage of this functionality, you can then scale the application horizontally to meet the demands of your application.
Apache Tomcat, and other containers, have been around for so long today that it has become increasingly harder to get started with them today.
In this article, we will take you back from the beginning with how to get started with Apache Tomcat. We will go into the lowest level, so you don't have to rely on an IDE or other system to get started. This article is written for those that have never used Apache Tomcat and wish to get started in an easy, yet explanatory, way that helps you to understand what is happening under the hood. This will fast track you to become very proficient with this light weight application server.
While there are a lot of different packages available to install Tomcat, for example some Linux distributions you can download it using that distributions package and dependency management. This is good, for the sake of simplicity, but once again, you lose the concept of what Tomcat is and what true dependencies it has as well on how to use it.
I strongly recommend only moving to a third party packaging of Apache Tomcat after you understand the container itself. This will help avoid complications when you try to create a plan for how you distribute, upgrade and maintain your software.
Rule 1. When learning, only download the software from http://tomcat.apache.org/
Now, since you are learning Apache Tomcat from scratch, I suggest you start with Apache Tomcat 7. As explained in an earlier post, the majority of features that are implemented, are driven by the (Servlet) and (JSP) specifications. Each time the Servlet specification is upgraded, new features added, the Apache Tomcat will plan for a new major release of Apache Tomcat. The latest version, Apache Tomcat 7, is based on the version of the Servlet specification, in this case, Servlet 3.0.
The Apache Tomcat team announces the immediate availability of Apache Tomcat 7.0.22
Apache Tomcat 7.0.22 includes bug fixes and new features compared to version 7.0.21 including:
Please refer to the change log for the complete list of changes:
Note that this version has 4 zip binaries: a generic one and three bundled with Tomcat native binaries for Windows operating systems runningon different CPU architectures.
Announced this morning by the Apache Tomcat team:
The Apache Tomcat team announces the immediate availability of Apache Tomcat 7.0.21
Apache Tomcat 7.0.21 includes security fixes, bug fixes and new features compared to version 7.0.20 including:
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.