High-Level Steps for Creating and Using tc Runtime Clusters

The following procedure outlines the main tasks you perform to create and configure a tc Runtime cluster from two or more tc Runtime instances.


It is assumed that you have already created the individual tc Runtime instances, on one computer or distributed over multiple computers. If this is not the case, see "Creating a New tc Runtime Instance" in Getting Started with vFabric tc Server.

  1. Prepare your Web applications so they can be deployed to a cluster and take full advantage of the tc Runtime clustering features. See Web Application Requirements for Using Session Replication.

  2. Be sure that you have correctly configured your network to enable multicast, which is the typical method of communication between cluster members. See Network Considerations.

  3. Configure your tc Runtime instances into a simple cluster using the default values for most of the configuration options. See Configuring a Simple tc Runtime Cluster.

  4. If the default configuration does not suit your needs, configure other cluster configuration options. See Advanced Cluster Configuration Options.

  5. Start your cluster by starting all the tc Runtime instances that make up the cluster group. You can do this manually, as described in "Starting and Stopping tc Runtime Instances" in Getting Started with vFabric tc Server, or by using the HQ User Interface.

Web Application Requirements for Using Session Replication

In addition to configuring the cluster from a server administration point of view, make sure your Web application meets these requirements:

  • All servlet and JSP session data must be serializable. In Java terms, this means that every field in the session object must either implement the java.io.Serializable interface or it must be transient.

  • tc Runtime uses cookies to track session state, which means that the Web application URLs for a particular session always look the same. If they do not, the tc Runtime instance creates a new session each time a client sends a message, which essentially disables session replication for that Web application.

  • Configure your Web application to be distributable, that is, suitable for running in a distributed environment such as a tc Runtime cluster. You can do this in one of two ways:

    • Add the <distributable /> element to the web.xml deployment descriptor of your Web application; <distributable /> is a child-element of the root <web-app> element. The web.xml file is located in the WEB-INF directory of your Web application. For example:

      <?xml version="1.0" encoding="UTF-8" ?>
      <web-app xmlns="http://java.sun.com/xml/ns/j2ee"
          <distributable />
          <display-name>HelloWorld Application</display-name>
    • If you do not want to change the web.xml deployment descriptor file of your Web application, you can use the tc Runtime-specific <Context distributable="true"> element to specify that one or all Web applications are distributable. You can specify this element in the CATALINA_BASE/conf/context.xml file if you want to make ALL Web applications of a particular tc Runtime instance distributable. For example:

      <?xml version="1.0" encoding="ISO-8859-1" ?>
      <Context distributable="true" >
      </Context >

      You can also add this element to specific context files to narrow its scope. For details, see The Context Container.

  • To enable application context replication, specify that your application context use the org.apache.catalina.ha.context.ReplicatedContext context implementation, rather than the default (org.apache.catalina.core.StandardContext). As described in the preceding bullet, you can update the CATALINA_BASE/conf/context.xml file as shown:

    <?xml version="1.0" encoding="ISO-8859-1" ?>
    <Context distributable="true" className="org.apache.catalina.ha.context.ReplicatedContext" >
    </Context > 

Network Considerations

Be sure that multicast is working on each computer that hosts members of the tc Runtime cluster.

If the computers that host your tc Runtime cluster also host other applications that use multicast communications, be sure that the other applications do not use the same multicast address and port as the tc Runtime cluster. This precaution eliminates unnecessary processing of irrelevant messages by the tc Runtime cluster. In addition to overhead and decreased performance, unnecessary processing can delay cluster communications, causing a cluster member to be marked failed when in fact it is alive but broadcast of its heartbeat messages is taking too long.