Clustering web applications on Tomcat - Part 2

<- Part 1 Part 3 ->

Now that we have the background, let's go ahead with the test.

For this test, we used the JPestStore application, which is a widely accepted reference implementation of a typical web application, using various components of the J2EE stack. We used the JPetStore implementation which is bundled with the The Spring Framework (v1.2.8) and can be downloaded here.

Simplicity

Tomcat:

To cluster JPetStore with Tomcat, we had to do the following:

• All the session attributes and the objects in their reference graph must implement java.io.Serializable
• Uncomment the Cluster element in server.xml
• Uncomment the Valve(ReplicationValve) element in server.xml
• If the Tomcat instances are running on the same machine, make sure the tcpListenPort attribute is unique for each instance.
• Make sure the web.xml has the element or set at your
• Make sure that jvmRoute attribute is set at your Engine
• Make sure that all nodes have the same time and sync with NTP service!
• Make sure that the loadbalancer is configured for sticky session mode.

In addition, the application had to make an explicit call to setAttribute() on the session to reduce network chattiness.

Terracotta:

With Terracotta Sessions, we were able to cluster the JPetStore application in under a few minutes, thanks to the really helpful configurator tool that is shipped with the product. The entire process involved firing up the configurator tool, importing the JPetStore war file from within the configurator and firing up the server instances. Done.

Terracotta clusters the sessions declaratively, which means we did not make any code changes or implement java.io.Serializable on session attributes. The entire process involves:

• Declaring the application name in the Terracotta configuration xml file (tc-config.xml).
• Fire up the Terracotta Server.
• Make a call to each Tomcat node in the cluster through Terracotta client script.

The configurator tool did all of the above for us. The configurator has another very useful feature called the Admin-Console which allowed us to look at behavior of our clustered application at run time.

<- Part 1 Part 3 ->