Purpose
This article gives an example of cluster configuration using static cluster membership (instead of determining it dynamically over multicast), and points out some important aspects of membership configuration. While multicast membership is simpler to set up, static membership is necessary on networks with multicast disabled.
Resolution
Example: This is an example element in server.xml from a node that is part of a 2-node static cluster. In this example, all nodes are on the same host. You can copy this example and modify hosts and ports as necessary for your own cluster.
This example differs from the default multicast configuration as discussed in the Apache Tomcat 6 Clustering how-to. These differences are important when creating your own non-multicast configuration:
- The McastService element is removed.
- The channelStartOptions=”3″ switch has been added to the Cluster element, to disable the multicast service. Even when not explicitly configured, the multicast service is enabled by default. If the multicast service is not disabled this way, and multicast is enabled on the network, your nodes could cluster with unexpected members. For more information about the Cluster element, see its entry in the Apache documentation.
- The TcpPingInterceptor class is added. This interceptor pings other nodes so that all nodes can recognize when other nodes have left the cluster. Without this class, the cluster may appear to work fine, but session replication can break down when nodes are removed and re-introduced. For more information about the TcpPingInterceptor element, see its entry in the Apache API documentation.
- The StaticMembershipInterceptor element is added at the end of the list of interceptors, specifying the other static members of the cluster. For more information about the StaticMembershipInterceptor element, see its entry in the Apache documentation.
Remember these points when modifying the configuration:
- As with the default configuration, you can use either the DeltaManager or BackupManager by changing the element.
The order of the interceptors is very important. Preserve the order presented here.Caution: Reversing the first two interceptors can results in a log full of messages similar to:
WARNING: Unable to send ping from TCP ping thread. java.lang.NullPointerException at org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.sendPing(TcpPingInterceptor.java:121) at org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor$PingThread.run(TcpPingInterceptor.java:166) - One member in the static list is commented out: the member that corresponds to the node on which this configuration file is located. Be sure not to include a node in its own cluster membership. If this were done, the node would sync to itself as if it were a different node in the cluster. With DeltaManager, that could lead to errors at startup like:
org.apache.catalina.ha.session.DeltaManager waitForSendAllSessions SEVERE: Manager [localhost#/petcare]: No session state send at [time] received, timing out after 60,087 ms. org.apache.catalina.ha.session.DeltaManager getAllClusterSessions WARNING: Manager [localhost#/petcare]: Drop message SESSION-GET-ALL inside GET_ALL_SESSIONS sync phase start date [times]
With the BackupManager this configuration is silently accepted, but the node would consider itself its own backup. Restarting the node would result in the loss of sessions not synced to other nodes.
Additional Information
This configuration is known to work with Tomcat 6.0.33. It does not work with Tomcat 7.0.22/23. For more information, see the Apache bug report.