http://www.terracotta.org/
If you look up Grid in Wikipedia there’s no simple answer, it starts… “Grid computing is a phrase in distributed computing which can have several meanings” it goes on to describe a number of meanings.
An interesting reason why grid has taken off is the sideways move in Moore’s law. In the past it was simply the clock speed or bus width that changed as we moved up the Moore’s law graph. In the past we could write a little for-loop and expect it to run roughly twice as fast every 24 months, that’s 1,000 times faster in 20 years. Over the last few years though this little for-loop will still be running at the same speed. Now clock speeds have peeked as distributing heat has become a major issue. We’ve already reached a brick wall at around 3-4GHz so to continue we’ve moved “sideways” into multi core. The difference today is that you can run three or more for-loops at the same time without slowing down the first one.
Why all this technie stuff? because I’m testing on Terracotta and all their benefities.
Terracotta is open source infrastructure software that makes it inexpensive and easy to scale a Java application to as many computers as needed, without the usual custom application code and databases used to share data in a cluster.
Terracotta manages mission critical data using Network-Attached Memory (NAM) technology. NAM enables Terracotta to cluster Java Virtual Machines (JVMs) directly underneath applications, and is a proven runtime approach to providing Java applications both high availability and scalability.
This article describe’s a simple java application following from the “The Definitive Guide to Terracotta: Cluster the JVM for Spring, Hibernate and POJO Scalability”
http://www.amazon.com/Definitive-Guide-Terracotta-Hibernate-Scalability/dp/1590599861
The idea is to have a simple java program HelloClusteredWorld.java (I include the package sample to understand clearly how to define it in the tc-config file)
package sample;
public class HelloClusteredWorld {
private static final String message = “Hello Clustered World!”;
private static final int length = message.length();
private static char[] buffer = new char [length ]; // This variable will be locked and shared
private static int loopCounter; // This variable will be locked and shared
public static void main( String args[] ) throws Exception {
while( true ) {
synchronized( buffer ) {
int messageIndex = loopCounter++ % length;
if(messageIndex == 0) java.util.Arrays.fill(buffer, ‘\u0000′);
buffer[messageIndex] = message.charAt(messageIndex);
System.out.println( buffer );
Thread.sleep( 100 );
}
}
}
}
Another requirement the tc-config.xml file which defines the way terracotta wil be integrated or viceverse.
<?xml version=”1.0″ encoding=”UTF-8″?>
<!–
All content copyright (c) 2003-2007 Terracotta, Inc., except as may otherwise be noted in a separate copyright notice. All rights reserved.
–>
<!–
This is a Terracotta configuration file that has been pre-configured for use with DSO. All classes are included for instrumentation, and all instrumented methods are write locked.
For more information, please see the product documentation.
–>
<tc:tc-config xmlns:tc=”http://www.terracotta.org/config”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://www.terracotta.org/schema/terracotta-4.xsd”>
<servers>
<!– Tell DSO where the Terracotta server can be found. –>
<server host=”localhost”>
<data>%(user.home)/terracotta/server-data</data>
<logs>%(user.home)/terracotta/server-logs</logs>
<dso>
<persistence>
<mode>permanent-store</mode>
</persistence>
</dso>
</server>
</servers>
<!– Tell DSO where to put the generated client logs –>
<clients>
<logs>%(user.home)/terracotta/client-logs</logs>
</clients>
<application>
<dso>
<roots>
<root>
<field-name>sample.HelloClusteredWorld.buffer</field-name>
</root>
<root>
<field-name>sample.HelloClusteredWorld.loopCounter</field-name>
</root>
</roots>
<!– Start by including all classes for instrumentation.
It’s more efficient to instrument only those classes that
hold shared roots or are part of a shared root’s graph.
–>
<instrumented-classes>
<include>
<class-expression>sample.HelloClusteredWorld</class-expression>
</include>
</instrumented-classes>
<!– Apply write level autolocks for all instrumented methods.
It’s more efficient to create finer-grain locks as dictated
by your application needs.
–>
<locks>
<autolock>
<lock-level>write</lock-level>
<method-expression>void sample.HelloClusteredWorld.main(..)</method-expression>
</autolock>
</locks>
</dso>
</application>
</tc:tc-config>
The servers and clients sections are self-explain and the real mess is located under the application section.
The roots are the fields which will be shared and locked in the application as you can see the buffer variable and loopCounter was wrapped around a root tag, plese take care to include the complete path for each variable including package and classname (sample.HelloClusteredWorld.buffer)
How do you execute it?
start your terractota server
C:\terracotta-3.2.0\bin\start-tc-server.bat
compile your class and execute it TWICE using :
C:\shared\Proyectos\Applications\HelloClusteredWorld>\terracotta-3.2.0\bin\dso-java.bat -jar HelloClusteredWorld.jar sample.HelloClusteredWorld
You will see both JVM are sharing the char[] buffer and int loopCounter, and try stopping and restarting one of the JVM, you will see the High Availability, screen attached:
