The Tomcat Servlet and JSP Engine

your location: home page ··· articles ··· java hosting ··· tomcat servlet and jsp engine

Article Summary

Title:		The Tomcat Servlet and JSP Engine
Description:		The Tomcat Servlet and JSP Engine, its configurations, and the benefits of the different configuration options.
Key Words:		Jakarta, Tomcat, servlet, jsp, engine, configuration, options
Type:		Articles
Category:		Java Hosting
Last Updated:		2003-02-04 10:23:47


	The Tomcat Servlet and JSP Engine The Jakarta Group's Tomcat Java Virtual Machine (JVM) is AO Industries' JVM of choice for several reasons, including its compliance with Sun's Java standards and the open source nature of its code. Tomcat also has an ardent industry following, as evidenced by its strong support from the likes of Sun Microsystems and IBM. Why We Use Tomcat As the reference implementation of Sun's Servlet and JSP specifications, Tomcat is guaranteed to be compliant with industry standards. Tomcat 3.x supports JSDK 2.2 and JSP 1.1, while Tomcat 4.x supports JSDK 2.3 and JSP 1.2. AO Industries supports several versions of Tomcat in order to achieve the greatest code compatibility coverage possible. An added benefit of Tomcat being a reference implementation is that most web applications have been developed, or at least tested for standards compliance, in a Tomcat JVM. Tomcat is a product of the Jakarta project, part of the Apache Software Foundation's family of open source software. Having the source code readily available online has been very helpful to us, allowing us to find the optimal configurations for both performance and security. Users can also feel confident knowing that Tomcat has benefited from the rigorous debugging and optimization performed by the large number of developers contributing to the Jakarta/Tomcat project. Tomcat's portable code leads to the simple use of Unix (Linux) symbolic links for the installation tree. A typical Tomcat installation in the AO Industries server environment including all of our default configuration and test pages occupies around 200KB. This small installation footprint keeps things running efficiently and reserves more space for web site content. The RAM consumption of Tomcat is also quite reasonable, and our typical managed server is capable of running hundreds of individual Tomcat JVMs without RAM contention. How We Use Tomcat When sharing Tomcat 3.x JVMs, our system uses custom code that starts a separate instance of Tomcat for each site in the JVM. These sites are then optionally isolated from each other through ThreadGroups and a custom SecurityManager. This leads to very reliable and seamless operation, but the downside is each JVM creates many Threads. Each thread is represented by a native Linux process table entry, which in turn fills the process space on a normal virtual server with many thousands of processes. Along with the introduction of Tomcat 4, the mod_jk interface between Apache and Tomcat has proven invaluable to our overall Java hosting system. The mod_jk module is a vast improvement over the older JServ interface in Tomcat 3.x. Using Apache JServ Protocol 1.3 (AJP13) connectors allows persistent connections with pooling, eliminating the need to establish a new TCP connection between Apache and Tomcat for each HTTP request. The mod_jk module also integrates better with Apache, providing more seamless environment supporting Java, PHP, CGI, and legacy systems. Where previous protocols simply assumed that a request on port 443 was secure, mod_jk provides Tomcat with all the information necessary to correctly identify when a request was made via HTTPS. A further minor improvement in Tomcat 4 is the integration of Catalina, a completely new code architecture that provides easier configuration and greater performance than Tomcat 3.x. Virtual hosting with a shared JVM in Tomcat 4 uses a combination of Apache virtual hosting and standard Tomcat virtual hosting. When an incoming connection is established, Apache resolves the correct port to connect to using AJP13. Upon connecting to Tomcat, Tomcat then performs its level of virtual hosting. Using this combination, the shared JVM allocates fewer ports and many fewer threads than our Tomcat 3 virtual hosting. The Tomcat 4 JVMs may also be security shared between clients using our custom security policies. We use a script generated policy file for very granular security. Each time the JVM is restarted, a Bourne shell script recreates the policy file, taking into account each JAR for each web site, granting appropriate permissions. One downside of this is that a new JAR file in a site does not receive file write permissions until the JVM is restarted. Overall, Tomcat has proven to be a stable and efficient servlet container. Some other products will benchmark higher. But when examining where a reasonably complex application uses most of its time, we find that Tomcat is only a small part of the overall picture. Taking this into account, any of the available performance increases do not out-weigh the benefits of Tomcat.