Friday, 22 June 2012

Infinispan 5.2 alpha out now with Command Line Inteface!

Infinispan 5.2.0.ALPHA1 has just been released and it comes with a load of new goodies, here's a summary:
Full details of all the rest enhancements can be found here. If you have feedback, please visit our forums. Finally, as always, you can download the release from here.


Infinispan CLI

When using Infinispan, both embedded as a library in an application or as a standalone server, I always longed for a simple standalone tool for interacting with the caches and the data within them. As all itches go, I had to scratch it, and so I present you with Infinispan's own CLI !

The CLI allows you to inspect and modify the data within an Infinispan cache and also provides access to some of the more advanced features (such as transactions).

The CLI is built out of two elements: a server-side module and the client command tool. The server-side module is optional, and provides the actual interpreter for the commands. Currently the server (and the client) use the JMX protocol to communicate, but in a future release we plan to support other communication protocols (in particular our own HotRod).

To get started, you need at least Infinispan 5.2.0.ALPHA1. Unzip the distribution and start a server:

./bin/ -r hotrod

The script automatically enables remote JMX connections and you can discover the port by running the jps command (part of the JDK/JRE) as follows:

jps -v

which should display something like

26532 Jps -Dapplication.home=/usr/lib/jvm/jdk1.7.0_04 -Xms8m
20508 Main"" -Dlog4j.configuration=file:////home/tst/Downloads/infinispan-5.2.0-SNAPSHOT/etc/log4j.xml

Now we can connect to the Infinispan instance using the CLI as follows:

./bin/ -c jmx://localhost:50434

You will be presented with a prompt:


The above prompt shows which host we're currently connected to and which CacheManager is being used (in this case: MyCacheManager).

Let's try putting some data in the cache

put a a

Now let's check that the cache actually contains the entry we've just put

get a

Which will display a glorious


The CLI understands several commands. Just type


to get a list of them and then

help [commandname]

to get help on a specific command's syntax.

The CLI uses the wonderful JReadline, so it supports all sorts of fancy buffer editing, history navigation and tab-completion as if you were in your comfortable OS shell (sorry Windows, cmd is not exactly a modern shell).

An important aspect of an Infinispan cache is that you can store whatever data you want in it. The CLI tries to interpret the data from the input you give it. It understands most of the Java native types (int, long, float, double, boolean, String), some additional fancy types (such as UUIDs) and a JSON syntax for mapping any type of Java class, so that you can write:

put user1 { "package.MyClass": {"i": 5, "x": null, "b": true } };

Conversely, when performing a get, the interpreter will output a JSON representation of your classes.

The CLI is still work in progress and will evolve and mature during Infinispan's 5.2 development cycle. You are all welcome to try it out and provide feedback on the forums, on IRC on channel #infinispan and using our issue tracker to report bugs and ask for enhancements.

I will soon be blogging again, hopefully with a video which will illustrate some of the more fanciful features of the CLI. Enjoy.

The JBoss Enterprise Data Grid tour!!

It's exciting times at the Infinispan team! Here's some of my highlights of the last few weeks and events coming up.

JBoss Enterprise Data Grid (based in Infinispan) presented in Spain's Red Hat JBoss Open Forum 2012

Yesterday I was in Madrid at Red Hat's JBoss Open Forum 2012, where I presented about JBoss Enterprise Data Grid and Clustering in JBoss Enterprise Application Plattform 6

This was a great opportunity to introduce these new products to a Spanish audience, and as with everything in Spain, if you present in the native language, people understand things better and are more likely to get a better impression. 

Might sound odd, but presenting this stuff in another language other than English, such as Spanish, is rather difficult even if you're a native speaker. If you've developed software in English, you're used to speaking about it in that language, but if you switch and you have to talk about in another language, getting the fluency required to tell a story (i.e. present something) takes a lot of preparation (write up notes in that language!) and above all, rehearsing.

The effort was worth it though! Having finished my first presentation, the JBoss Enterprise Data Grid one, I was non-stop talking to the Spanish sales force, potential Spanish customers...etc for the rest of the day, until I had to present again.

Last time I attended a JBoss middleware event in Spain was in Barcelona in 2006. A long time has passed since then, but what Red Hat Spain's JBoss Forum shows is that JBoss Middleware is back in the Iberian peninsula, and it's there to stay for a long time!!

Special thanks to Lucas Ponce who helped out massively with the live demos of both JBoss Enterprise Data Grid and JBoss Enterprise Application Plattform 6, and thanks to the rest of Red Hat Spain team who invited me to speak at the event.

JBoss World/Red Hat Summit and JUDCon in Boston

Heiko Rupp and I will be speaking about JBoss Enterprise Data Grid monitoring with JBoss Operations Network, which we're both hugely looking forward to! So, if you're around, don't miss the talk next Thursday at 2.30pm EDT (abstract can be found here)


Thursday, 21 June 2012

Fine-grained replication in Infinispan

Sometimes we have a large object, possibly with lots of attributes or holding some binary data, and we would like to tell Infinispan to replicate only certain part of the object across the cluster. Typically, we wanna replicate only that part which we've just updated. This is where DeltaAware and Delta interfaces come to play. By providing implementations of these interfaces we can define fine-grained replication. When we put some effort into such such an enhancements, we would also like to speed up object marshalling and unmarshalling. Therefore, we're going to define our own externalizers - to avoid slow default Java serialization.

The following code snippets are gathered in a complete example at This project contains a readme file with instructions on how to build and run the example. It is based on clustered-cache quickstart in Infinispan.

Implementing DeltaAware interface

So let's look at our main object. For the purpose of this exercise, I defined a Bicycle class that consists of many components like frame, fork, rearShock, etc. This object is stored in a cache as a value under certain (not important) key. It might happen in our scenario that we update only certain components of the bike and in such case we want to replicate just those component changes.

Important methods here are (description taken from javadocs):

commit() - Indicates that all deltas collected to date has been extracted (via a
                 call to delta()) and can be discarded. Often used as an optimization if
                 the delta isn't really needed, but the cleaning and resetting of       
                 internal state is desirable.

delta() - Extracts changes made to implementations, in an efficient format that
             can easily and cheaply be serialized and deserialized.  This method will
             only be called once for each changeset as it is assumed that any
             implementation's internal changelog is wiped and reset after generating
             and submitting the delta to the caller.
We also need to define setters and getters for our members. Setter methods are, among other things, responsible for registering changes to the changelog that will be later used to reconstruct the object's state. The externalizer for this class is only needed when cache stores are used. For the sake of simplicity, I don't mention it here.

Implementing Delta interface

Actual object that will be replicated across the cluster is the implementation of Delta interface. Let's look at the class. First, we need a field that will hold the changes - changeLog. Second, we need to define a merge() method. This method must be implemented so that Infinispan knows how to merge an existing object with incoming changes. The parameter of this method represents an object that is already stored in a cache, incoming changes will be applied to this object. We're using a reflection here to apply the changes to the actual object but it is not necessary. We could easily call setter methods. The advantage of using reflection is that we can set those fields in a loop.

Another piece is a registerComponentChange() method. This is called by an object of the Bicycle class - to record changes to that object. The name of this method is not important.

Defining our own externalizer

Alright, so what remains is the externalizer definition for the Delta implementation. We implement AdvancedExternalizer interface and say that only changeLog object should be marshalled and unmarshalled when transfering data over the wire. A complete (almost) implementation of Delta interface is the following.

Tell Infinispan about the extra externalizer

We also need to configure Infinispan to use our special externalizer to marshall/unmarshall our objects. We can do it e.g. programatically by calling .addAdvancedExternalizer() on the serialization configuration builder.

You can see we're also configuring transactions here. This is not necessary, though. We just aim to provide a richer example, removing transactional behavior is trully easy.

And here comes the "usage" part. Enclose cache calls by a transaction, retrieve a bicycle object from the cache, do some changes and commit them.

That's it. What is eventually transferred over the wire is just the changeLog object. The actual bicycle object is reconstructed from incomming updates.

If all of this seem to be too complex to you, I have good news. Infinispan provides one implementation of DeltaAware interface whish is called AtomicHashMap (package org.infinispan.atomic). If this map is used as a value in key/value pairs stored in the cache, only puts/gets/removes performed to this map during a transaction are replicated to other nodes. Classes like Bicycle and BicycleDelta are not need then. Even registering the externalizer for AtomicHashMap is not needed, this is done automatically during registration of internal externalizers. However, one might want a class emulating a real-world object, not just a map. That's the case when your own implementations of DeltaAware and Delta interfaces are the only way.

Wednesday, 20 June 2012

You can now buy support for Infinispan

Yes, at last.  Intentions first announced last year, and beta programme launched a few months ago, Red Hat's JBoss Data Grid (JDG) 6.0 is now in final, GA form.  This supported release is based on Infinispan 5.1.5.Final, and you can read more about it here.

It has been picked up by the press too.

Open source.  And enterprise-grade.  :-)


Thursday, 14 June 2012

Back from Berlinbuzzwords

I'm back from the berlin buzzwords conference where I've been talking about the datagrids performance. 
I've been told by several people how good this conference was - but even so I was very surprised by the quality of both the presenters and audience. The conference is very focused on data relates topics (scale, search, store) so it was great picking up the brains of so many data enthusiasts. The beer wasn't that bad either. 
A big thanks to the organizers for the this excellent event and hope that infinispan be part of next year's agenda.