The default multicast address and port of a cluster are 228.0.0.4 and 45564, respectively. Sometimes you need to change these values; for example, suppose you want to configure two clusters on the same computer, one for testing and one for production. The easiest way to set this up is to specify different multicast/port combinations for the two clusters.

To change the multicast address and port of a cluster, update the server.xml file for each tc Runtime instance that is a member of the cluster and add or update the <Membership> child element of the <Channel> element, which itself is a child member of the <Cluster> element.

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
   <Channel className="org.apache.catalina.tribes.group.GroupChannel">

      <Membership className="org.apache.catalina.tribes.membership.McastService"
                  address="228.1.0.4"
                  port="55564" /> 

   </Channel>

</Cluster>

Use the address and port attributes of the <Membership> element to set the multicast address and port; in the preceding example, the new values are 228.1.0.4 and 55564, respectively.

For more information on the <Membership> element, its default behavior, and the attributes you can set to further configure it, see The Cluster Membership Object.

The default implementation of the cluster group notification is built on multicast heartbeats sent using UDP packets to a multicast IP address. As described in the general cluster documentation, you group cluster members by specifying the same multicast address/port combination (either using the default values or custom values). Each member then sends out a heartbeat within a given interval (frequency); this heartbeat is used for dynamic discovery. The cluster membership listener listens for these heartbeats; if the membership listener does not receive a heartbeat from a node within a certain timeframe (droptime), the cluster considers the member suspect and notifies the channel to take appropriate action.

The default frequency at which members send heartbeats (500 milliseconds) is typically adequate. On high-latency networks, you might want to increase the default value of the drop time (3000 milliseconds) to protect against false positives.

To change the drop time, update the server.xml file for each tc Runtime instance that is a member of the cluster and add or update the <Membership> child element of the <Channel> element, which itself is a child member of the <Cluster> element.

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
   <Channel className="org.apache.catalina.tribes.group.GroupChannel">
      <Membership className="org.apache.catalina.tribes.membership.McastService"
                  dropTime="6000" /> 
   </Channel>

</Cluster>

Use the dropTime attribute of the <Membership> element to set the drop time; in the preceding example, the new drop time value is 6000 milliseconds.

For more information on the <Membership> element, its default behavior, and the attributes you can set to further configure it, see The Cluster Membership Object.

The default cluster configuration uses the DeltaManager object to enable all-to-all session replication, which means that the cluster replicates the session information (typically session deltas) to all the other nodes in the cluster, including nodes in which the application is not even deployed. (In this context, a node refers to a tc Runtime instance that is a member of the cluster.) All-to-all replication works well for smaller clusters that are made up of just a few nodes. However, the DeltaManager requires that all nodes in the cluster be homogeneous and that all nodes must deploy the same applications and be exact replicas.

Therefore, if you have configured a large cluster with many nodes, or you find the requirements of the DeltaManager too limiting, SpringSource recommends that you configure the cluster so that it replicates to just a single backup node by using the BackupManager object. The cluster ensures that the node to which it replicates also has the application deployed. The location of the backup node is known to all nodes in the cluster. Finally, because the cluster is replicating to just one node, the cluster supports heterogeneous deployment.

To configure use of a single backup node for session replication, add or update <Manager> child element of the <Cluster> element in the server.xml files for all tc Runtime instances that are members of the cluster, as shown in the following snippet:

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
   <Manager className="org.apache.catalina.ha.session.BackupManager" /> 
</Cluster>

For additional information about the BackupManager, its default behavior, and the attributes you can set on the <Manager> element, see The ClusterManager Object.