/dev/websphere

Creating disk snapshots of an IBM WebSphere eXtreme Scale grid and why they are really useful

I've been working with a few customers who are using WXS to load large quantities of data in to the grid from a database. This can be quite time consuming as fetching the data from the backend is usually the bottleneck. Loading hundreds of gigabytes of data can take well over an hour. This means that a full grid restart is not something such a customer wants to do a lot given the cost of reloading the data.

The bottleneck here isn't WXS, it's the source data system. Many of the customer scenarios I see use the grid as the system of record. If the grid is down then the data doesn't change. We'll discuss when it does change later.

I've written a utility as part of wxsutils (if you're not using this with wxs then you are missing out...). It will make a disk based snapshot of a grid map. It writes each partition for each map to a file by writing the key/value pairs as JSON strings. Each physical box hosting the grid container JVMs will store all the partitions hosted on that box in files in a particular folder on that boxes file system. The current code does it for the maps you specify. So, just execute the code once for each map you want 'snapshotted'.

Later, the customer can execute the read snapshot code to reload that data set from those files in to the grid. This will happen at grid speed. Each box in the grid will read the local files and load them in to the grid as fast as possible. The bottleneck here will likely be network depending on the boxes.

This approach can save a lot of time in many scenarios:

• The customer wants to cycle the whole grid for maintenance on the WXS runtime or the application artifacts. The customer should snapshot the grid before stopping it and then read the snapshot after restarting the grid post maintenance. This is much faster than a reload from the backend.
• The customers wants during testing to have a grid with a well known start data set. Load it once, snap shot it and then use it to reset the grid every time you want to run a test case from a well known start state.

If the data is changing all the time even when the grid is down then we can deal with that also. Probably the 'best' (and best is a loose word here) way to synchronize a grid with a database is by using a change data capture type product. For example, here is IBMs link. These products watch the transaction logs of a database and allow an application to intercept changes in the data without slowing the database down or using triggers etc. The application listener would then typically make a message about the change and send it to the grid where the grid will process the message and apply the change. This keeps the staleness between the database and the grid to a minimum.

If this listener stores these messages in a JMS queue or MQ series queue then even if the grid is down, these changes are tracked. Thus, when the grid is restarted, do not start the msg listener straight away. Instead do the read snapshot and then start the listener which will down apply all changes since we wrote the snapshot. This allows a delta update of the data in this case keeping the snapshot useful.

You can see how to use this snapshot capability on github at this link.

You will need to add the PerContainerGrid definition to your objectgrid.xml and deployment.xml files and put wxsutils.jar and the jackson json jars also on your container classpaths.

Easily run queries across all data in IBM WebSphere eXtreme Scale

I just uploaded a small sample showing how to run a query across all data in an IBM WebSphere eXtreme Scale grid. I'll use a simple example to show how it works. Lets assume we have a Grid with a map called Person containing a String/Person pair. The key is a String, the value is the Person object. The Person object looks like this. The objectgrid.xml file needs to have a schema defined so we can run queries against it. The reason for this is so WXS can do reflection to type check the queries before execution and so on.

Here is a code snippet showing how to use a GridQuery to get all the rows in the grid:

GridQuery q = new GridQuery(ogclient, "select p from Person p", 100);
ArrayList<Object> block = q.getNextResult();
while(block != null)
{
    for(Object r : block)
    {
        Person p = (Person)r;
        System.out.println(p.toString());
        Assert.assertEquals(true, personSet.remove(p.getFirstName()));
    }
    block = q.getNextResult();
}

This shows a client using its ogclient connection to run the query and print out all the answers. The query runs across all data returning entries in blocks of at most 100 at a time. A junit test case exercising it is contained in this sample.

The code to achieve this is contained in the package 'com.ibm.devwebsphere.wxsutils.multijob" and its subpackage. You can just include it in your application if you'd like but make sure to add the RoutingI32Key map which is just used for routing not for any storage. Make sure you have defined a schema also.

Javascript based grid operations client on github

I get asked a lot if WebSphere eXtreme Scale includes a utility to examine the contents of a grid and/or allow the grid to be manipulated. I've uploaded the first version of such a utility to my github repository today. 

https://github.com/bnewport/Samples/tree/master/jsoncrud/

I'll add the README from the project here:

This is a command line utility that allows you to work with a remote grid and examine/manipulate it. It's built around a JavaScript shell. When you start the utility then you specify the grid you want to connect to:

> jsonclient.sh -ch localhost -cp 2809 -grid Grid 

I'm assuming you've created a jsonclient.sh script to call "com.devwebsphere.jsoncrud.WXSShell". This is the main class. This will then connect to the grid and start up a JavaScript shell like this: 

Rhino 1.7 release 2 2009 03 22

js> 

At this point there is one global variable defined called 'grid'. You can use this to get instances of Maps in the remote grid. For example: 

js> personMap = grid.getMap("Person", "java.lang.String", "com.billy.Person")

 This stores a Map object instance for Person in the personMap variable. The map is stored remotely in the grid and uses a String for the key with a value using the class com.billy.Person

Lets suppose your Person looks like this:

public class Person implements Serializable 

{

String firstName;

String middleInitial;

String surname;

Date dateOfBirth;

double creditLimit;

...

}

 

The class would have getters and setters define for the attributes. You can insert a Person entry using this:

js> billy = {"firstName":"Billy", "surname":"Newport", "middleInitial":"Z", "creditLimit":"100.0"}

js> personMap.put("bn", billy)

 

This creates an entry in the map with the key "bn" and the value as shown. The value in the remote Map is a Person class instance. The JSON string above needs to have the same corresponding attributes as the Person POJO. We can modify the entry so have a different credit limit like this:

js> p = personMap.get("bn")

js> p.creditLimit = 200

js> personMap.put("bn", p)

 

We can remove the entry like this:

js> personMap.remove("bn")

 

We can invalidate the entry like this:

js> personMap.invalidate("bn")

Preparation Instructions

Add the jars to the grid classpath. Add a map called "Router" to your mapset. It is just used for routing, no data is stored in it. The client doesn't need any application classes. Once this is done then you should be able to connect to the grid and work as described above

 

 

Detecting eviction events on a WebSphere extreme Scale client

I've just pushed another sample to github. This sample shows how to attach a listener to the grid which watches transactions involved a set of maps. Any eviction events in those maps are 'noticed' and an eviction event is inserted in to a map thats basically used like a simple queue. I wrote a client side listener that can be attached to a client grid reference. This listener polls the server side grid looking for these events and returns them to the client.

The particular use case that prompted this sample was a customer using the grid to store application sessions and they needed a way for applications to be notified when the grid evicted their sessions. They wanted EVERY application JVM to see EVERY eviction. This is important to realize. Every eviction event will be processed by every application JVM instance. If we just needed the eviction event to be handled by exactly one application JVM then I'd write it using the getNextKey function in WXS.

The test package has sample objectgrid.xml and deployment.xml files as well as a test case showing how to invoke the client to test it.