From Fri Dec 25 20:10:24 2009 Return-Path: Delivered-To: Received: (qmail 17197 invoked from network); 25 Dec 2009 20:10:24 -0000 Received: from (HELO ( by with SMTP; 25 Dec 2009 20:10:24 -0000 Received: (qmail 97620 invoked by uid 500); 25 Dec 2009 20:10:23 -0000 Delivered-To: Received: (qmail 97542 invoked by uid 500); 25 Dec 2009 20:10:23 -0000 Mailing-List: contact; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: List-Id: Delivered-To: mailing list Received: (qmail 97533 invoked by uid 99); 25 Dec 2009 20:10:23 -0000 Received: from (HELO ( by (qpsmtpd/0.29) with ESMTP; Fri, 25 Dec 2009 20:10:23 +0000 X-ASF-Spam-Status: No, hits=-1994.1 required=10.0 tests=ALL_TRUSTED,HTML_MESSAGE,MIME_HTML_ONLY,OBFUSCATING_COMMENT X-Spam-Check-By: Received: from [] (HELO ( by (qpsmtpd/0.29) with ESMTP; Fri, 25 Dec 2009 20:10:21 +0000 Received: from (localhost []) by (Postfix) with ESMTP id 0738E234C045 for ; Fri, 25 Dec 2009 12:10:00 -0800 (PST) Date: Fri, 25 Dec 2009 20:10:00 +0000 (UTC) From: To: Message-ID: <> Subject: [CONF] Apache Geronimo v2.1 > Tomcat Native Clustering MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Auto-Submitted: auto-generated X-Virus-Checked: Checked by ClamAV on

Tomcat Native Clustering

Page edited by Ashish Jain


The Tomcat Web container provides a native clustering solution that can = be configured through Geronimo using gbean definitions within config.xml or= your deployment descriptors . This document will go through the available = GBeans and how to configure them for clustering in a Geronimo server with a= tomcat web container.
A cluster configuration should be considered when you want to improve the s= calability and availability of your Web application. The following sections= provide detailed instructions on how to set up your cluster nodes and how = to deploy your applications with tomcat clustering enabled.

= Setting up a clustering environment

Generally, to set up a small cluster you will need at least 2 nodes and = 1 HTTP server. The HTTP server is used to serve requests from clients and e= nsure well-balanced traffic load among different nodes. Similarly, each nod= e is configured to use the same logical Tomcat engine and enable session af= finity.

Planning you= r cluster

The Tomcat cluster replicates HTTP session data via memory to memory mul= ticast communication.

Every node transmits its session data to every node in the cluster. This= algorithm is only efficient when the clusters are small. If the clusters g= row too large, the overhead in storage utilization and network traffic beco= mes excessive. To avoid excessive overhead, consider dividing your nodes in= to several smaller clusters.

HTTP session data is replicated among the nodes in the cluster using a m= ulticast broadcast. All nodes in the cluster must be on the same physical s= ubnet and multicast broadcast must be supported by that subnet.

Prep= aring your Web application

To participate in a cluster configuration, your Web application must be = implemented correctly.

  • Ensure that every object placed in the HTTP session implements java.= io.Serializable. The clustering feature serializes the objects when it dist= ributes them to the other nodes in the cluster.
  • =09
  • The deployment descriptor for your Web application, that is the = web.xml file in the Web archive, must indicate that your Web applicati= on is distributable. To do this, insert the distributable element in= the deployment descriptor.
    Excerpt from web.xml
    <?xml version=3D"1.0=
    " encoding=3D"ISO-8859-1"?>
    <!DOCTYPE web-app
        PUBLIC "-//Sun Microsystems, Inc.//DTD Web A=
    pplication 2.3//EN"
        <display-name> ... </display-name>
        <description> ... </description>
        <distributable> <distributable/>
  • Do not use stateful session Enterprise JavaBeans (EJBs). The cluster= ing feature does not replicate stateful EJBs among the nodes in the cluster= .
  • =09
  • If your Web application uses a database, make sure the database can = be accessed from every node in the cluster. Ensure that the proper JDBC dri= vers are installed on every node and that the datasource objects are define= d correctly on every node.
  • =09
  • Do not depend on dynamic updates to the Java Naming and Directory In= terface (JNDI). You will need to configure all the JNDI names used by your = application in every node of the cluster. The clustering feature does not r= eplicate JNDI changes among the nodes in the cluster.

Enable Ses= sion Affinity

Support for session affinity, also known as sticky session support, allo= ws a load balancing service to route an HTTP request back to the same node = that created the HTTP session associated with that request until that node = fails. You must use session affinity if you configure an asynchronous type = of session replication. With asynchronous replication, the reply is returne= d before the HTTP session is replicated so there is always a chance that th= e next request using that session arrives before the replication is complet= e. In this case, the only way to ensure that the request is processed using= the correct session data is to route the request to the node that sent the= reply to the last request and originated the replication.

For every node in the cluster, update config.xml as follows after the se= rver is stopped

Excerpt from config.xml
<gbean name=3D"Tomca=
  <attribute name=3D=

Engaging load balancing and failover

Initially, the server configuration includes an AJP connector suitable f= or exchanging messages with a load balancing service. See Configuring a remote Apache HTTP se= rver for more information about the HTTP server configuration.