The Cluster object
Table of Contents
The tomcat cluster implementation provides session replication, context attribute replication and
cluster wide WAR file deployment.
Cluster configuration is fairly complex, the default configuration will work
for most people out of the box.
The Tomcat Cluster implementation is very extensible, and hence we have exposed a myriad of options, making the configuration seem like a lot, but don't lose faith, instead you have a tremendous control over what is going on.
The cluster implementation is written on the basis that a secure, trusted network is used for all of the cluster related network traffic. It is not safe to run a cluster on a insecure, untrusted network.
There are many options for providing a secure, trusted network for use by a Tomcat cluster. These include:
- private LAN
- a Virtual Private Network (VPN)
Engine vs Host placement
You can place the
<Cluster> element inside either the
container or the
Placing it in the engine, means that you will support clustering in all virtual hosts of Tomcat, and share the messaging component. When you place the
<Cluster> inside the
element, the cluster will append the host name of each session manager to the managers name so that two contexts with
the same name but sitting inside two different hosts will be distinguishable.
Context Attribute Replication
To configure context attribute replication, simply do this by swapping out the context implementation used for your application context.
This context extends the Tomcat
so all the options from the base implementation are valid.
The session manager element identifies what kind of session manager is used in this cluster implementation. This manager configuration is identical to the one you would use in a regular
The default value is the
org.apache.catalina.ha.session.DeltaManager that is closely coupled with
SimpleTcpCluster implementation. Other managers like the
are/could be loosely coupled and don't rely on the
SimpleTcpCluster for its data replication.
The Channel and its sub components are all part of the IO layer for the cluster group, and is a module in it's own that we have nick named "Tribes"
Any configuring and tuning of the network layer, the messaging and the membership logic will be done in the channel and its nested components. You can always find out more about Apache Tribes
The Tomcat Cluster implementation uses
Tomcat Valves to
track when requests enter and exit the servlet container. It uses these valves to be able to make
intelligent decisions on when to replicate data, which is always at the end of a request.
The Deployer component is the Tomcat Farm Deployer. It allows you to deploy and undeploy applications cluster wide.
ClusterListener's are used to track messages sent and received using the
If you wish to track messages, you can add a listener here, or you can add a valve to the channel object.
Deprecated configuration options
Deprecated settings: In the previous version of Tomcat you were able to control session manager settings using manager.<property>=value. This has been discontinued, as the way it was written interferes with the ability to support multiple different manager classes under one cluster implementation, as the same properties might have the different effect on different managers.
The main cluster class, currently only one is available,
The Tribes channel send options, default is
Some of the values are:
You may also set these options as a comma separated string, e.g. "async, multicast", which
will be translated into
Sets the start and stop flags for the <Channel> object used by the cluster.
The default is
To start a channel without multicasting, you would want to use the value
Flag whether invoke channel heartbeat at container background thread. Default value is false. Enable this flag don't forget to disable the channel heartbeat thread.
Flag whether notify LifecycleListeners if all ClusterListener couldn't accept channel message. Default value is false.