Java

Tomcat 6 & 7 – Best Practices

Introduction

This guide shows you how to setup and run your Tomcat instances in a multi-tenant environment. It also shows you how to effectively design your provisioning, monitoring, and security model around Tomcat in a flexible manner.

The information in this guide is based on practices learned from customer feedback and product support, as well as experience from the field and in the trenches. The guidance is task-based and presented in the following parts.

  • Part I – Tomcat Overview – gives you quick overview of Tomcat as provided out-of-the-box by Apache, how it launches, and how it can be configured.
  • Part II – Security – gives you a quick overview of fundamental security concepts as they relate to Tomcat.
  • Part III – Configuration – gives you a quick overview of fundamental configuration options and concepts as they relate to performance, management, monitoring, and application configuration.
  • Part IV – Scenarios – gives you an overview of key scenarios with the use of Tomcat, with a focus on Intranet/Internet scenarios and clustering.

Scope of This Guide

This guide is focused on delivering a production ready strategy for large scale deployment of Tomcat in a sensible and extensible fashion into production environments. This approach can also be used on a local developer station (either Windows or Linux) to create a baseline.

Out of Scope

  • Java Language
  • Application Specific Scenarios

Why We Wrote This Guide

From our own experience with Tomcat and through conversations with customers and co-workers who work in the field, we determined there was demand for a guide that would show how to use Tomcat in the real world. While there is information in the product documentation, in blog posts and in forums, there has been no single place to find proven practices for the effective use of Tomcat in the context of line of business applications under real world constraints.

Who Should Read This Guide

This guide is targeted at providing individuals involved in building applications with Tomcat. The following are examples of roles that would benefit from this guidance:

  • A development team that wants to adopt Tomcat.
  • A software architect or developer looking to get the most out of Tomcat, with regard to designing their infrastructure, enhancing performance, and deployment scenarios.
  • Interested parties investigating the use of Tomcat but don’t know how well it would work for their deployment scenarios and constraints.
  • Individuals tasked with learning Tomcat.
  • A enterprise architect looking to promote the use of Tomcat in their line-of-business applications
  • Individuals tasked with automating the deployment of applications into Tomcat.

How To Use This Guide

Use the first part of the guide to gain a firm foundation in key concepts around Tomcat. Next, use the application scenarios to evaluate potential designs for your scenario. The application scenarios are skeletal end-to-end examples of how you might design your authentication, authorization and communication from a production Tomcat perspective. Use the appendix of “Guidelines”, “Practices”, “How To” articles and “Questions and Answers” to dive into implementation details. This separation allows you to understand the topics first and then explore the details as you see fit.


Part I – Tomcat Overview

Objectives

  • Learn the basic requirements for Tomcat
  • Learn what is provided by Tomcat out-of-the-box
  • Learn how to start and stop a basic Tomcat instance

Overview

This chapter provides a set of foundational building blocks on which to base your understanding of Tomcat. Additionally, this chapter introduces various terms and concepts used throughout this guide.

Tomcat Minimum Requirements

Tomcat Layout

The keys to building a scalable tomcat solution includes the understanding of two key environment properties used by tomcat and what they mean.

  • CATALINA_HOME – represents the static files used by tomcat server such as the lib and bin directories.
  • CATALINA_BASE by default is set to CATALINA_HOME. CATALINA_BASE allows for the logical separation of tomcat and line-of-business applications.

CATALINA_HOME

/bin
This directory is never used during runtime. It’s sole purpose is to store scripts and to startup and shutdown tomcat along with resolve classpaths.

/lib
Contains the jars that make up Tomcat Server and any dependencies Tomcat server has.

/endorsed
By default a folder that does not exist when Tomcat is first downloaded. It is a reserved folder that when created allows for global level JARs to be placed and loaded by all Tomcat instances. It is best practice for JDBC drivers and any other classes that may utilize the J2SE 1.4 endorsed feature. In short, there are some package names from which classes are only loaded if the package files are located in the endorsed directory.

CATALINA_BASE

/conf
This directory contains configuration information for the specified application.

/webapps
This is where you place your applications that run within TC. (defined by server.xml)

/work
This is a server level working directory for your web applications. (defined by server.xml)

/logs
Runtime logs generated when you run tomcat. (defined by logging.properties)

/temp
This directory is used by the JVM for temporary files. (defined by java.io.tmpdir)

Scenarios

  • Intranet – Line of Business Web Application Server
  • Intranet – Line of Business Web Services Server
  • Internet – Application Web Application Server
  • Internet – Application Web Services Server

Intranet – Line of Business Web Application Server

Scenario

You want to provide a means to host web based applications within your company. These applications are all require a Java servlet container and you wish to standardize the deployment, configuration, and hosting into a single unified platform of development. This includes the standardization of tomcat across the environments and the ability to support multiple lines of development with minimal impact to each business area.

Key Characteristics

This scenario applies to you if:

  • Operate within a corporate IT department
  • Need a standard Java servlet hosting environment
  • Are restricted by resources and/or skill-sets and need the simplest possible option
  • Need a means to have a stepping stone to more robust vendor solutions
  • Have many paths of development and many applications in different stages of development
  • Require occasional customizations of servlet containers and can not afford to offload work to individual teams
  • You need the ability to run multiple JVMs – largely because some teams and/or some applications may need to run on legacy JVMs and you do not want to restrict other teams or applications from using a newer JVM
  • You need the ability to run multiple versions of tomcat quickly and easily with a standard interface
  • You need the ability to run multiple versions of tomcat to upgrade without having to re-implement core configuration options.
  • You need the ability to upgrade to a vendor provided solution like springsource should the resources become available without additional effort.

Solution

Leverage Tomcat’s built in ability to separate the core Tomcat server from web application specifics through the use of the out-of-the-box provided CATALINA_HOME and CATALINA_BASE configuration options.

Intended Benefits

By implementing this solution the following benefits can be reached by the organization;

  • You may find that the separation of applications makes outages less painful and more granular increasing operational efficiency
  • A clear understanding of the environment makes communication across departments easier
  • Through standardization comes the possibility to create automated solutions for provisioning new application servers, increasing efficiency and reducing impacts to workers
  • By separating each application into it’s own container allows for finer grained performance tuning and customization of a particular application
  • Operations will now be able to effectively troubleshoot performance problems down to a particular application, memory leaks and performance and health metrics can be tailored and targeted to diagnose and resolve issues without impacting other parties.
  • Development efforts can happen in parallel with minimal impacts to other teams, shutting down and restarting a development or sqa server for a application only effects that application.

Possible Side Effects

By creating a script solution you may encounter the following smells;

  • Individuals or teams may start referring to their applications using specific port numbers rather than canonical names.
  • By allowing unlimited expansion the number of web applications may grow and the need for more hardware may be required
  • By making it easier to deploy applications you may forget application justification processes, always justify the creation of any new application or service, and always due buy vs. build analysis

Other alternatives

Buy vs. build analysis on cloud based solutions and/or vendor provided solutions like springsource tcserver.

Solution Implementation Details

To provide this solution to your organization download from the Apache the appropriate versions of Tomcat you wish to provide along with the JVM of your choice. We are going to assume the latest installation as of this writing which is Tomcat 7.0.14.

  1. Download Tomcat 7.0.14
  2. Create a new folder /opt/dev/tomcat
  3. Unzip apache-tomcat-7.0.14 into /opt/dev/tomcat
  4. Create a new file run.sh inside /opt/dev/tomcat
  5. Create a new file server.sh inside /opt/dev/tomcat
  6. Create a new directory /opt/dev/tomcat/shared – this will hold server wide configuration information
  7. Copy server.xml in apache-tomcat-7.0.14/conf to ./shared
  8. Copy logging.properties in apache-tomcat-7.0.14/conf/logging.properties to ./shared

Provisioning a new Tomcat Instance

The convention used for creating a new tomcat instance is the creation of a new folder that contains the CATALINA_BASE core folder structure. This folder is given the same name as that of the port you wish Tomcat to use.

This allows for dynamically provisioning of a new Tomcat instances by simply creating the default CATALINA_BASE directory structure within a folder named the port number you wish to use.

By using this convention a system administrator can quickly understand what ports are being claimed by Tomcat and ensure there are no overlaps in port numbers. This also provides the capability that any startup/shutdown scripts will also pick up the new instance without the need to modify any /etc/init.d/ scripts so that any restart of the server will also pick up these changes.

Example – Provision A New Instance on Port 7051

  1. Create a new directory called /opt/dev/tomcat/7051
  2. Create the following directories [./bin, ./conf, ./logs, ./temp, ./work, ./webapp] inside 7051; mkdir -p /opt/dev/tomcat/7051/{bin,conf,logs,work,webapp,temp}
  3. Copy the default web.xml from your tomcat install directory cp /opt/dev/tomcat/tomcat-7.0.14/conf/web.xml /opt/dev/tomcat/7051/conf
  4. Optionally – create a new file setenv.sh inside ./7051/bin which will hold application specific customizations such a garbage collection options (see: example setenv.sh)

Now the configuration and provisioning is complete you should be able to start tomcat:
/opt/dev/tomcat/run.sh 7051 start

What remains is to deploy your application(s) to this tomcat instance by copying the wars to:
/opt/dev/tomcat/7051/webapps/

run.sh

server.sh

Automatic Startup/Shutdown of Multi Instance Tomcat

Enterprise applications need to have the ability to survive a restart of the server. By combining what you have now learned about tomcat and the new ability to run multiple instances you can now turn to the startup and shutdown of Tomcat using /etc/init.d.

  1. Create a new file in /etc/init.d called tomcat
  2. Run sudo chmod 755 /etc/init.d/tomcat
  3. Run /sbin/insserv -d tomcat

Fix Performance for SecureRandom creation of Sessions Taking Too Long


03-Jul-2011 20:33:19.272 INFO org.apache.catalina.util.SessionIdGenerator.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [68,810] milliseconds.

Problem is that it took 69 seconds for tomcat to startup because of the Session ID generation. This really isn’t acceptable and ignored by Sun as “not being a bug”.

References:
http://stackoverflow.com/questions/137212/how-to-solve-performance-problem-with-java-securerandom
http://comments.gmane.org/gmane.comp.jakarta.tomcat.user/210075

Standard

9 thoughts on “Tomcat 6 & 7 – Best Practices

  1. marco says:

    Hello, I’m using your scripts as a base for another set of scripts. I’m wondering what is the license of your scripts and if I’m allowed to reuse your work.
    Please contact me privately.

    Thanks

  2. j.k. says:

    I just configured it as in the tutorial.
    But when i start server.sh all tomcats – even if the folders name of the tomcats are 8080 7000 or 8050 are or want to start with http pot 8080.

    But at the start of server.sh in the information the ports are set correctly. What is wrong????

  3. j.k. says:

    Sorry. I don’t start server.sh but run.sh. Only there are at the start dislayed informations. But the tomcat starts only at port 8080

    • admin says:

      Sorry, I don’t quite understand. But the commands are “./run.sh start” the port must be the same as the folder name and you must use the provision.sh to create the specified ports. For example “./provision.sh 8080” to create a new folder for 8080.

  4. Pingback: tomcat7-install-and-setenv | mauroprogram's Blog

  5. M.Mounir says:

    Hi,

    Thank you for this interesting architectural solution.

    Did you make changes to your server.xml , because i see you send http port like this -Dhttp.port=$HTTP_PORT”
    and i think you make somthing like that on your server.xml

    Regards,

Leave a Reply

Your email address will not be published. Required fields are marked *