Clustering and Load Balancing in Tomcat 5, Part 2
Subject:   4 Tomcat Servers
Date:   2006-10-25 23:07:05
From:   suhaib
Response to: 4 Tomcat Servers

I am new to Tomcat and infact new to this domain. I am trying to set up 4 Tomcat servers in a cluster and one of them will act as load balancer. (This one does both load balacing and server the requests). Moreover, I need a way to design a load balancing scheme where I can dynamically balance the load among all the available servers. (Balanced load in contrast to random or round robin which does work this way). Moreover any of the server can go down and comes up but not the load balancer one which always stays up.

I have read a couple of articles but none seems to answer my questions as no one really explains the things in the server.xml and rules.xml. I have no clue to what these are and how these are manil]pulated to get the desires results. ( Java sucks full time and it seems that it does not have any direcion so far, I am a C programmer).

I will highly appreciate if someone can tell me what needs to be modified in the server.xml and rules.xml or other file to get this work done.

Moreover WHAT is these lines in server.xml (the first server LOAD BALANCER in this article) doing:

<Manager className="org.apache.catalina.session.PersistentReplicationManager"



<Store className="org.apache.catalina.session.FileStore"

directory="E:\web\tomcat50\work" />


These lines are not in the other servers servers.xml files nor in my server.xml file

I am using tomcat 5.5:
Finally what does this means:
"extract the contents of the zip file to the tomcat directories."Do we have to overwrite all the files in the tomecat folder with these folders. Do I need "ServerUtil" class or other rule classes in tomcat 5.5.

This is my server.xml file
<!-- Server Configuration File for Tomcat 5 on Debian
You can find a more complete example in /usr/share/doc/tomcat5/examples/

<!-- Note that component elements are nested corresponding to their
parent-child relationships with each other -->

<!-- A "Server" is a singleton element that represents the entire JVM,
which may contain one or more "Service" instances. The Server
listens for a shutdown command on the indicated port.tcpListenPort

Note: A "Server" is not itself a "Container", so you may not
define subcomponents such as "Valves" or "Loggers" at this level.

<Server port="8005" shutdown="SHUTDOWN" debug="0">

<Listener className="org.apache.catalina.mbeans.ServerLifecycleListener"
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"

<!-- Global JNDI resources -->

<!-- Test entry for demonstration purposes -->
<Environment name="simpleValue" type="java.lang.Integer" value="30"/>

<!-- Editable user database that can also be used by
UserDatabaseRealm to authenticate users -->
<Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" pathname="conf/tomcat-users.xml"/>

<ResourceParams name="UserDatabase">


<!-- A "Service" is a collection of one or more "Connectors" that share
a single "Container" (and therefore the web applications visible
within that Container). Normally, that Container is an "Engine",
but this is not required.

Note: A "Service" is not itself a "Container", so you may not
define subcomponents such as "Valves" or "Loggers" at this level.

<!-- Define the Tomcat Stand-Alone Service -->
<Service name="Tomcat-Standalone">

<!-- Define a non-SSL Coyote HTTP/1.1 Connector on port 8180 -->
<Connector className="org.apache.coyote.tomcat5.CoyoteConnector"
port="8180" maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="true" acceptCount="10" debug="0"
connectionTimeout="20000" useURIValidationHack="false" />

<!-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 -->
<Connector className="org.apache.coyote.tomcat5.CoyoteConnector"
port="8009" maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="true" acceptCount="10" debug="0"
connectionTimeout="20000" useURIValidationHack="false"

<!-- An Engine represents the entry point (within Catalina) that processes
every request. The Engine implementation for Tomcat stand alone
analyzes the HTTP headers included with the request, and passes them
on to the appropriate Host (virtual host). -->

<!-- Define the top level container in our container hierarchy
The name must be Catalina for correct function of the admin webapp -->
<Engine name="Catalina" jvmRoute="node01" defaultHost="localhost" debug="0">

<!-- Global logger unless overridden at lower levels
<Logger className="org.apache.catalina.logger.FileLogger"
prefix="catalina_" suffix=".log" timestamp="true"/>
<!-- Because this Realm is here, an instance will be shared globally -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
debug="0" resourceName="UserDatabase"/>

<!-- Define the default virtual host -->
<Host name="localhost" debug="0" appBase="webapps"
unpackWARs="true" autoDeploy="true">

<!-- Defines a cluster for this node,
By defining this element, means that every manager will be changed.
So when running a cluster, only make sure that you have webapps in there
that need to be clustered and remove the other ones.
A cluster has the following parameters:

className = the fully qualified name of the cluster class

clusterName = a descriptive name for your cluster, can be anything

mcastAddr = the multicast address, has to be the same for all the nodes

mcastPort = the multicast port, has to be the same for all the nodes

mcastBindAddress = bind the multicast socket to a specific address

mcastTTL = the multicast TTL if you want to limit your broadcast

mcastSoTimeout = the multicast readtimeout

mcastFrequency = the number of milliseconds in between sending a "I'm alive" heartbeat

mcastDropTime = the number a milliseconds before a node is considered "dead" if no heartbeat is received

tcpThreadCount = the number of threads to handle incoming replication requests, optimal would be the same amount of threads as nodes

tcpListenAddress = the listen address (bind address) for TCP cluster request on this host,
in case of multiple ethernet cards.
auto means that address becomes

tcpListenPort = the tcp listen port

tcpSelectorTimeout = the timeout (ms) for the method in case the OS
has a wakup bug in java.nio. Set to 0 for no timeout

printToScreen = true means that managers will also print to std.out

expireSessionsOnShutdown = true means that

useDirtyFlag = true means that we only replicate a session after setAttribute,removeAttribute has been called.
false means to replicate the session after each request.
false means that replication would work for the following piece of code: (only for SimpleTcpReplicationManager)
HashMap map = (HashMap)session.getAttribute("map");
replicationMode = can be either 'pooled', 'synchronous' or 'asynchronous'.
* Pooled means that the replication happens using several sockets in a synchronous way. Ie, the data gets replicated, then the request return. This is the same as the 'synchronous' setting except it uses a pool of sockets, hence it is multithreaded. This is the fastest and safest configuration. To use this, also increase the nr of tcp threads that you have dealing with replication.
* Synchronous means that the thread that executes the request, is also the
thread the replicates the data to the other nodes, and will not return until all
nodes have received the information.
* Asynchronous means that there is a specific 'sender' thread for each cluster node,
so the request thread will queue the replication request into a "smart" queue,
and then return to the client.
The "smart" queue is a queue where when a session is added to the queue, and the same session
already exists in the queue from a previous request, that session will be replaced
in the queue instead of replicating two requests. This almost never happens, unless there is a
large network delay.
When configuring for clustering, you also add in a valve to catch all the requests
coming in, at the end of the request, the session may or may not be replicated.
A session is replicated if and only if all the conditions are met:
1. useDirtyFlag is true or setAttribute or removeAttribute has been called AND
2. a session exists (has been created)
3. the request is not trapped by the "filter" attribute

The filter attribute is to filter out requests that could not modify the session,
hence we don't replicate the session after the end of this request.
The filter is negative, ie, anything you put in the filter, you mean to filter out,
ie, no replication will be done on requests that match one of the filters.
The filter attribute is delimited by ;, so you can't escape out ; even if you wanted to.

filter=".*\.gif;.*\.js;" means that we will not replicate the session after requests with the URI
ending with .gif and .js are intercepted.

The deployer element can be used to deploy apps cluster wide.
Currently the deployment only deploys/undeploys to working members in the cluster
so no WARs are copied upons startup of a broken node.
The deployer watches a directory (watchDir) for WAR files when watchEnabled="true"
When a new war file is added the war gets deployed to the local instance,
and then deployed to the other instances in the cluster.
When a war file is deleted from the watchDir the war is undeployed locally
and cluster wide

<Cluster className="org.apache.catalina.cluster.tcp.SimpleTcpCluster"




<Valve className="org.apache.catalina.cluster.tcp.ReplicationValve"

<Valve className="org.apache.catalina.cluster.session.JvmRouteBinderValve" enabled="true" sessionIdAttribute="takeoverSessionid"/>

<ClusterListener className="org.apache.catalina.cluster.session.ClusterSessionListener"/>
<ClusterListener className="org.apache.catalina.cluster.session.JvmRouteSessionIDBinderListener" />

<Deployer className="org.apache.catalina.cluster.deploy.FarmWarDeployer"


<!-- Normally, users must authenticate themselves to each web app
individually. Uncomment the following entry if you would like
a user to be authenticated the first time they encounter a
resource protected by a security constraint, and then have that
user identity maintained across *all* web applications contained
in this virtual host. -->
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />

<!-- Access log processes all requests for this virtual host. By
default, log files are created in the "logs" directory relative to
$CATALINA_HOME. If you wish, you can specify a different
directory with the "directory" attribute. Specify either a relative
(to $CATALINA_HOME) or absolute path to the desired directory.
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs" prefix="localhost_access_log." suffix=".txt"
pattern="common" resolveHosts="false"/>

<!-- Access log processes all requests for this virtual host. By
default, log files are created in the "logs" directory relative to
$CATALINA_HOME. If you wish, you can specify a different
directory with the "directory" attribute. Specify either a relative
(to $CATALINA_HOME) or absolute path to the desired directory.
This access log implementation is optimized for maximum performance,
but is hardcoded to support only the "common" and "combined" patterns.
<Valve className="org.apache.catalina.valves.FastCommonAccessLogValve"
directory="logs" prefix="localhost_access_log." suffix=".txt"
pattern="common" resolveHosts="false"/>

<!-- Logger shared by all Contexts related to this virtual host.
<Logger className="org.apache.catalina.logger.FileLogger"
directory="logs" prefix="localhost_" suffix=".log"