Day 1 Session 3: Visualizing and Managing JVM Clusters

Presenter: Ari Zilka: Terracotta

This presentation set out to teach about JVM-level clustering by demo by showing a visualization of a clustered application.  It was a very interactive session with a lot of collaboration with the audience that allowed for suggestions on different ways to solve clustering issues. In situations where there were trade offs such as scalability vs. availability it followed a choose-your-own-ending style.  Terracotta was introduced and brought to bear on the situation allowing us great visibility into the clustering to allow for intelligent decisions to be made about where to choose what trade offs.

Terracotta helps with many of these aspects.  Briefly, Terracotta enables JVM-level clustering by stripping away the Business Logic aspect of a POJO (the code in the methods) from the state of the POJO (the properties and footprint).  It does this by taking over the heap which is where all the important state data is stored.  It takes control of the heap and clusters it within Terracotta.  What this looks like when an object is instantiated on a JVM it checks for the existence of that object on the graph.  Since it is the first time, it isn't found so normal instantiation ensues.  The second time that object is instantiated however, the check is made and the object is found on the graph.  Terracotta intervenes here and hands the constructor the previously constructed object's 'pointer.'  The initial object becomes what they refer to as the super static root object and all subsequent objects become nodes on that tree.  This super static root is a 'singleton' across the JVM cluster.  The Terracotta implementation is capable of outperforming other API systems 10X over in some cases. 

Terracotta uses the standard XML configuration file to make it aware of all the roots and constructs something called Distributed Shared Objects (DSOs).  It offers rich Eclipse plugins for doing these things.  The administration console utilizes JMX and gives incredible visibility into every aspect of the clustered solution during runtime.  It is good to note that you must treat your POJO like any other shared or multi-threaded object and use locks if you care anything at all about consistency. 

While it looks like an implementation using Terracotta would take a fair amount of planning, strategy and design with Terracotta in mind as well as making sure your objects are structured to take the best advantage of the Terracotta strengths, it appears that this would be well worth while to accomplish scalability goals on any enterprise deployment. 

-mw