Hi! Welcome...

I am Ashish. I am Member of Apache MINA PMC, ASF Committer and avid Code hacker. Contact me at paliwalashish at gmail dot com. I work for Terracotta [http://www.terracotta.org] as Solution Architect. I contribute to jsmpp [http://code.google.com/p/jsmpp/] as well.

24 March 2010 ~ 0 Comments

Caching and Database Offloading – Best of both worlds with Terracotta Darwin Release

Ehcache Terracotta

Abstract

The Terracotta Darwin release a feature packed release. I love to call it a Developer's delight. Integrating Terracotta with existing apps has been simplified a lot with Express Mode. In this series we shall see some touch upon some of the new features of the Darwin release

How is this post organized?

We shall take a sample Use Case(s), and discuss the needs. Using the Use Case we shall see the fitment of Terracotta features. Discussion will be around the following

  • Bulk Loading to Cache
  • Write Behind Cache

The Use Case - Bulk Loading

Bulk loading the cache is a common need for Cache warmup. Here we try to load the data into Cache in a single go, rather then on Cache miss. This help us in reducing the database lookup upon each miss.

Some Use Cases
Case 1: For a Catalogue site, loading all the available catalogues/Products during startup

catalogue_use_case

The cache can be loaded at the startup with the hot set o Products or as desired, against loading it at runtime, upon a Cache miss.

Case 2: For an Element Management System, loading all the Managed Devices into cache, available to all nodes in the cluster

ems_use_case

For an EMS Device Information for the Devices it is managing is used most often. The Device info can be bulk loaded at the startup. The example show the use of cache by a Poller, which Polls the Device status.

There are other common use cases. Please add comment with your Use case.

Ehcache Bulk Loading with Terracotta

Terracotta Darwin release has optimized bulk loading in Ehcache. In normal scenario, loading elements in Ehcache, would update the cache entry to all the clustered caches, making the bulk loading a bit slower.

Let's see how bulk loading in action

      // Get the Cache to be preloaded
      Cache ehcache = CacheManager.getInstance().getCache("mycache");

      // Set this property before bulk loading
      ehcache.setNodeCoherence(false);

      // Load everything here
      loadCache(); 

      // reset the property
      ehcache.setNodeCoherence(true);

      // Wait for all data to be distributed across cluster
      ehcache.waitUntilClusterCoherent();


What's being done inside the loadCache()?
Here is a glimpse

private void loadCache() {
   // Query the DB get the data and get the result into array
   // or what ever data structure you need

   // iterate over result and put into cache
   for(int i = 0; i < data.length; i++) {
       Element element = new Element(data.getId, data);
       ehcache.put(element);
   }
}


Here is how the cache look when we are bulk loading the data. We are using both nodes to load distinct data to speed up loading process. The loading can be taken care by a single node also.

ehcache - While Bulk uploading


Once the bulk loading is completed, and Nodes are set to coherent again, the data is replicated across the cluster, and all Nodes have the same data set.

ehcache - After Bulk upload


What's Next?
In the next post we shall cover the Write-Behind feature of Ehcache for DB offloading. I will rewrite the code of one my previous post Exploring Terracotta tim-async - Scalable way to off-load DB updates from App Transaction, to use the write-behind feature.


Tags: , ,

09 February 2010 ~ 0 Comments

So you want Distributed, Scalable and Highly Available Cache?

Ehcache Terracotta

Abstract

So you want Distributed, Scalable and Highly Available Cache? If yes, then this is the right place for you. The Terracotta Ehcache release has these features inbuilt. The Express Installation mode has simplified Terracotta integration in your application.

How this post is organized
First we shall start with simple standalone cache and then see how Terracotta can easily help us create a Distributed, Scalable and Highly Available cache, with a few minor configurations

What all do you need run the example?

  • Terracotta 3.2.0 - Download it from here


Sample Application
Lets design a sample application (a real simple one), which we shall use to demonstrate the features. Device Monitoring is a common requirement in OSS System, and caching the Device information reduces the Database hits. The essential components of our application are
- DevideInfo - A POJO that stores device information
- CacheHandler - Class that handles cache initialization and other ops

Lets see the CacheHandler class, which is the heart of our implementation

public class DeviceInfo  implements Serializable {

    String deviceId;

    String name;

    // .... other device information

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getDeviceId() {
        return deviceId;
    }

    public void setDeviceId(String deviceId) {
        this.deviceId = deviceId;
    }
}

The class is simple and contains information related to the device.

Let see our CacheHandler class

public class CacheHandler {

    public Cache deviceCache;

    public void initCache() {
        // Initialize the CacheManager
        CacheManager cacheManager = CacheManager.create();
        // Get the Cache to store device information
        deviceCache = cacheManager.getCache("deviceCache");
    }

    public void addToCache(DeviceInfo device) {
        Element el = new Element(device.getDeviceId(), device);
        deviceCache.put(el);
    }

    protected int getDeviceCacheSize() {
        return deviceCache.getSize();
    }

    public static void main(String[] args) {
        CacheHandler handler = new CacheHandler();
        handler.initCache();

        // Lets add 10 devices
        // just to keep life simple
        for(int i = 0; i < 10; i++) {
            DeviceInfo device = new DeviceInfo();
            device.setDeviceId("Device-"+i);
            handler.addToCache(device);
        }

        // Not recommended in production
        System.out.println("Cache Size = "+handler.getDeviceCacheSize());

    }
}

The class has two main functions
- initCache - The API initializes the cache
- addToCache - The API adds the device information to the device cache

Lets see our ehcache.xml

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="ehcache.xsd"
             updateCheck="true" monitoring="autodetect">

   <defaultCache
            maxElementsInMemory="10000"
            eternal="false"
            timeToIdleSeconds="120"
            timeToLiveSeconds="120"
            overflowToDisk="true"
            diskSpoolBufferSizeMB="30"
            maxElementsOnDisk="10000000"
            diskPersistent="false"
            diskExpiryThreadIntervalSeconds="120"
            memoryStoreEvictionPolicy="LRU"
            />

    <cache name="deviceCache"
           maxElementsInMemory="1000000"
           maxElementsOnDisk="1000"
           eternal="false"
           overflowToDisk="false"
           diskSpoolBufferSizeMB="20"
           timeToIdleSeconds="100"
           timeToLiveSeconds="100"
           memoryStoreEvictionPolicy="LFU">
     </cache>

</ehcache>

In the configuration we have defined a deviceCache, that we shall use to store device information.

Following is the list of jars you would need to run this app

  • ehcache-core-1.7.2.jar
  • slf4j-api-1.5.8.jar
  • slf4j-jdk14-1.5.8.jar

All these jars are available as part of Terracotta installation under /distributed-cache directory

You can run this example and see the same in action.


Making it Distributed....

Now lets assume that we want to make the Cache fault tolerant, survive JVM crashes, as well as have it available on different JVM's. It should be able to Scale as we add more JVM's to it and other stuff. With Terracotta, we can just do it in a few steps without changing the code. the magic lies with Express Installation mode, introduced in Terracotta version 3.2.0 and above

Lets see the 3 steps that we need to perform

1. Updates to the ehcache.xml
Add following element to ehcache.xml

<terracottaConfig url="localhost:9510" />

and for the deviceCache, we add <terracotta /> element

here is the updated ehcache.xml

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="ehcache.xsd"
             updateCheck="true" monitoring="autodetect">

   <terracottaConfig url="localhost:9510" /> 

   <defaultCache
            maxElementsInMemory="10000"
            eternal="false"
            timeToIdleSeconds="120"
            timeToLiveSeconds="120"
            overflowToDisk="true"
            diskSpoolBufferSizeMB="30"
            maxElementsOnDisk="10000000"
            diskPersistent="false"
            diskExpiryThreadIntervalSeconds="120"
            memoryStoreEvictionPolicy="LRU"
            />

    <cache name="deviceCache"
           maxElementsInMemory="1000000"
           maxElementsOnDisk="1000"
           eternal="false"
           timeToIdleSeconds="100"
           timeToLiveSeconds="100"
           memoryStoreEvictionPolicy="LFU">

        <terracotta />
     </cache>

</ehcache>

There is no need to change the code :-)

2. Add ehcache-terracotta-1.8.0.jar to the classpath

Lets start the Terracotta Server

3. Goto Terracotta_Install_dir/bin and execute

$ ./start-tc-server.sh

This shall start the Terracotta server

Now run the application on multiple JVM's. The device information is available on all client JVM's :-)

To monitor Cache, you can use Terracotta Dev Console

If you have further question/queries, please visit Terracotta Forums.

What's coming up Next?
The next post shall touch on write-behind feature in the latest Terracotta Darwin release. Its essentially to get best of both worlds - Caching and Database Offloading :-) Stay tuned..


Tags: ,

25 January 2010 ~ 3 Comments

Exploring Terracotta tim-async – Scalable way to off-load DB updates from App Transaction

Terracotta

Lets start this chat with a small conversation

Manager: What are the options we have to increase the TPS of our SMSC Server?

Architect: Can you elaborate a bit on this?

Manager: As of now we process a request and update the Database in the same tranaction. Essentially, we are operating our Server at the TPS at which our DB can operate.

Architect: Well we have to ensure that our Data is persisted

Manager: Yes, but can't we update the DB asynchronously, without lossing data

Architect: Yes it can be done, but we have to create a lot of infrastructure code around this, so that we don't loose data for failed transaction, process crashes etc.

If you have been in such a situation, the post is meant for you.

Summary

For any request, don't update the Database in same transaction, but data need to be persisted. This has always been a typical need to increase the liveliness of the application. The application accessing data in memory work must faster, than fetching/updating data form databases. Assume you have a solution which helps you to work in memory and allows your application to update the data to Datastore in separate transaction, providing HA and Scalability out of the box. If this is what you are looking at, Terracotta async processor (tim-async) is the right fit for you.

The article is organized to detail what tim-async is, followed by a sample application.

We shall see tim async in brief and then later would walk through the a small POC that I build around the same.

Pre-requisite

You should have basic understanding of Terracotta 3.2 and its Configuration.
You need to download tim-async using tim-get tool

What is tim-async?

tim stands for Terracotta Integration Module, and tim-async is module for asynchronous processing. tim-async provides a scalable, high performance way to asynchronously write the business data to data source (typically a database), while the application works on in-memory data structures. Decoupling the main processing from the underlying database decreases the write latency of domain objects, while high availability of data is provided by terracotta.

What features does it have

  • Multithreaded write behind to flush the processed data from the client VMs (L1s) to the data source
  • Data to be flushed remains highly available (HA) as it is shared with terracotta.
  • Every client takes the responsibility of writing its data set to the data source
  • Listeners to monitor work progress at bucket level.

NOTE: Have pulled out this information from the attachment here

Building Blocks of tim-async from User Perspective

From a User's POV, these three are the important building blocks

  • ItemProcessor
  • AsyncCoordinator
  • AsyncConfig

These are all classes/interface that are part of tim-async. Lets look at them in brief

ItemProcessor

Its an interface and the implementation class of this interface is where we shall be writing the actual processing logic of the Domain Object, like persisting it to the DB.

public interface ItemProcessor<I> {
public void process(I item) throws ProcessingException;
}

AsyncCoordinator

Its a core class and need to be declared as Shared Root in tc-config.xml. It allows work to be added and processed asynchronously.
The class has a method start() that needs to be called by every client node (Terracotta L1) to participate in processing.
An ItemProcessor instance is local to the node, so its the right place to hold stuff DB Connection etc

AsyncConfig

Its an interface and can be implemented to custom tailor the configuration of Async processing. If we don't define one, the org.terracotta.modules.async.configs.DefaultAsyncConfig is used.

public interface AsyncConfig {
public long getWorkDelay();

public long getMaxAllowedFallBehind();

public boolean isStealingEnabled();
}

Now lets see how can we implement tim-async in our application (We shall see the sample application)

- We need to implement ItemProcessor for doing custom processing say for example putting the stuff in DB
- We need to initialize AsyncCoordinator and call start() API, pass on the ItemProcessor from previous step as a param.
- Create tc-config.xml (pick teh sample from tim-async example), add the AsyncCoordinator field instance as the root
- Start TC Server and Client JVM's with tc-config.xml created above


Lets see these steps in Action.

Sample Application

I had written a SMSC simulator based on jsmpp which used to receive the SubmitSM request from Client, used to persist in the DB and return
the id to the client. There is a specific reason why I choose this application. I already had this running and since the SubmitSM just needed to persisted in DB for subsequent processing by other process. The business case was justified that the Server is very responsive to Client, as well as its ensured that the Data is persisted.

Lets walk through the a simple processing sequence

  • Client send a SubmitSM request
  • Server translated it into an internal SMS POJO, assigns a unique ID to the SMS
  • Server persists the SMS in Database
  • Sever sends the ID generate as part of SubmitSM response

The application uses Hibernate to save the POJO in MySQL Database.

Since the Domain object is least significant so won't discuss the internals of SMS POJO

Lets see how we enhanced the application to asynchronously update the DB

Implementing the ItemProcessor

public class AsyncSMSProcessor implements ItemProcessor {
public void process(final SMS sms) throws ProcessingException {
Session hibernateSession = DAO.getSession();
DAO.getSession().getTransaction().begin();
DAO.getSession().save(sms);
DAO.getSession().getTransaction().commit();
}
}

Essentially what we have to write the logic of saving the SMS object to the database. This is the object that Terracotta is going to pass back to us.
What we do here is save the SMS in a Hibernate transaction. This completes out ItemProcessor code

Initialize AsyncCoordinator

public class SMSProcessor {

public AsyncCoordinator asyncUpdator;

public SMSProcessor() {
asyncUpdator = new AsyncCoordinator();
// Use the default API

asyncUpdator.start(new AsyncSMSProcessor());

}

}

public long processIncomingSMS(SubmitSm submitSm,
SMPPServerSession source, ...) {

// some logic here
// give the date to AsyncCoordinator
asyncUpdator.add(sms);
// some logic there

}

This is the change that we have done here. Earlier we used to save the SMS in DB here. We have now given the data to AsyncCoordinator for subsequent processing.

Let's look at the tc-config.xml

this is what we need to add to the tc-config.xml

<application>
<dso>
<!--Declaring a field of a class a root will make it available for all instances
of our app that runs via DSO-->
<roots>
<!-- XXX: -->
<root>
<field-name>com.tc.timasync.demo.smsAsyncCoordinator</field-name>
</root>
</roots>
</dso>
</application>

We declared the AsyncCoordinator variable as DSO root here, which makes it shared across cluster.

That's it.

We are ready. Now we start Terracotta server with our tc-config file and start our SMSC Simulator as TC Client.

How does it all fit together

As we see the instead of updating the DB in the same transaction, we handed the data over to Terracotta. Essentially, this meant that our data has gone to Server, and won't be lost against crashes. The application operated at memory speed and responded to client. The Terracotta Server based on the configuration of tim-async shall call the ItemProcessor in different transaction. We can have multiple nodes updating the DB asynchronously or some other way, based upon the Use Case.

Let's run the both the implementations


Note on Comparison of both the implementations

I shall run both the implementation on the same hardware/OS, which would be my Laptop with 2GB of RAM, runnning Windows and MYSQL 5.X. The comparison shall be relative for the two implementation approached, and not the absolute figures. The figures would be much better if the samples are run on higher end machined with Terracotta Server (L2) running on a dedicated machine and the Clients (L1) running on different machines. The idea here is just to see the TPS of the Server.

Case I: DB updates in App transaction

For 10 runs of sending 1000 SubmitSM request client took following time

Total Time for 1000 SMS = 28891
Total Time for 1000 SMS = 34234
Total Time for 1000 SMS = 27812
Total Time for 1000 SMS = 34547
Total Time for 1000 SMS = 29953
Total Time for 1000 SMS = 34344
Total Time for 1000 SMS = 33985
Total Time for 1000 SMS = 35328
Total Time for 1000 SMS = 36968

Case II: DB updates based on tim-async

Total Time for 1000 SMS = 1359
Total Time for 1000 SMS = 1125
Total Time for 1000 SMS = 781
Total Time for 1000 SMS = 813
Total Time for 1000 SMS = 750
Total Time for 1000 SMS = 719
Total Time for 1000 SMS = 703
Total Time for 1000 SMS = 719
Total Time for 1000 SMS = 718
Total Time for 1000 SMS = 735

There was a significant decrease in the processing time of request :-)

What's next

Download Terracotta from here and try yourself. You can also register for upcoming Darwin release, which has many new interesting features

Resources

  • http://blog.terracottatech.com/2009/02/offloading_a_db_even_when_upda.html - A wonderful post by Ari
  • http://www.slideshare.net/sbtourist/real-terracotta-presentation
  • http://forums.terracotta.org/forums/forums/list.page


07 January 2010 ~ 1 Comment

Joined Terracotta

Personal

Finally, after a sprint of 9+ years at Hughes family, I started a new career. Started my work life with Hughes Software Systems in 2000, then joined Hughes Systique in 2006.

Year 2009 was a year of happenings for me. As I got more involved with Open Source software, my thoughts towards Software Development changed drastically. While involved in Apache MINA mailing list, was introduced to Terracotta. Well this was the beginning and later on I got hired:-) (off-course I applied for it).

Well now the easy life is gone, have much more challenging tasks ahead and at Terracotta, I will be working with some of the finest talent in the industry. A long road ahead for me. The biggest reason for joining Terracotta, Passion. This little word was common between me and most of the folks I interacted at Terracotta. Its very close to my punch line "Great passions can defy Destiny".

With my joining Terracotta as Solution Architect, I am very hopeful that my contribution towards Open Source community will increase significantly.

Before I close this post, a lot of credit to this success goes to Emmanuel Lecharny. He initiated me into Open Source and has been mentoring me all the way.

Wish you a very Happy New Year !

26 November 2009 ~ 0 Comments

Essential Components of Terracotta based Application

Terracotta

Abstract

How does a Terracotta Application look like? What are the essential components that make up the application? These were the question I had after writing my first post “Getting Started with Terracotta”. Here I try to take a quick look at these questions from a Users point of view. Please note that this post doesn’t try to dive deep into Terracotta inner working.


Components of Terracotta based Application

Components of Terracotta based Application

To keep life simple, have considered the general application architecture, which essentially can be any Terracotta app. From the figure we can see that we have four different parts that contribute to a complete Terracotta app.

User Application – These are applications that want to use Terracotta to Scale. They can either use Terracotta transparently or can use explicit Terracotta API’s

Terracotta Server – It’s the nerve center. Terracotta applications can’t run without it. For running any TC application, it’s a must to run atleast one TC Server.

Terracotta config file – Also known as tc-config.xml (default name). It provides the detailed configuration for Server as well as Client. It contains information like Server’s IP’s, persistence mode, classes to instrument etc.

Terracotta Libraries – These are essentially part of Client or User applications. They are the work horses of the running application and enables Terracotta integration with User application. An example would be dso-java.bat script adds the Terracotta bootjars to the classpath, enabling Terracotta features for the application.

So how does it all fit together at runtime

  • Start Terracotta Server, providing a configuration file with desired configuration
  • Start User Application using dso-java.(bat|sh) instead of normal java, along with a configuration file
  • That’s it :-)


1 2 3 4 »Last »