GridGain 2.1 Preview

I would like to give a preview of GridGain 2.1 release. We are very excited about this ucoming release as it brings many enhancements and new features to our product mostly based on the user and customer feedback that we have been getting.  Here are some new features that you will see in 2.1 release.

Per-Task SPI Customization

Now you will be able to configure different sets of SPI's for different tasks. For example, Task1 and Task2 can have different topology and load-balancing policies.

Node Filters and Apache JEXL

You will be able to specify grid node topology based on Apache JEXL expression language directly from XML configuration or from code. The example below will include all nodes that have more than one processor, CPU load less than 70%, and belonging to 'worker-segment' configured by user.

(node.metrics.availableProcessors > 1) &&
(node.metrics.currentCpuLoad < 0.7) &&
(node.attributes.get('segment').equals('worker-segment')

LifeCycle Beans

You will be able to hook into GridGain lifecycle using LifeCycle Beans. Basically GridGain will be able to receive a collection of LifeCycle Beans on startup and then it will invoke callbacks on those beans once life cycle events occur.

Customizable Marshalling And XML Serialization

GridGain will now come with 3 optional implementations of marshalling: Jboss, JDK, and XStream XML-based. Default value will remain to be JBoss Serialization, but now you will be able to easily switch to JDK serialization, or for cases where you need to exchange non-serializable data, you will be able to use XStream XML-based serialization.

Database Job Checkpoints

Prior to 2.1 you had ability to store checkpoings in Shared File System or distributed caches. Starting with 2.1, GridGain will support ability to store intermediate checkpoints for long running jobs in database.

Tighter Spring Integration

In GridGain 2.1 you will be able to inject Spring beans into your grid tasks and jobs by simply annotating fields or methods with "@GridSpringBean(name)" annotation. You also will be able to configure the whole GridGain as a Spring bean and wire it up via Spring configuration files.

Peer-Class-Loading For Grid Event Querying

Now you will be able to query events without having to deploy event filters on all grid nodes. For example, the following code will give you all events from all grid nodes without any extra deployment steps:

Grid grid = GridFactory.getGrid();

Collection<GridNode> allNodes = grid.getAllNodes();

Collection<GridEvent> evts = grid.queryEvents(myEventFilter, allNodes);

Flexible Deployment Modes

This is a very big change for us as it really enhances GridGain "Code->Compile->Run" philosophy. As many of you know, there are no explicit deployment steps when working with GridGain - the deployment happens automatically, but now users will be able to control how classes and user resources should be shared across grid. Prior to 2.1, users had only the option of every task being loaded through its own separate class loader, which made it somewhat inconvenient to share classes and resources between tasks. Now, the behavior of class-loading on remote nodes will absolutely resemble class-loading on local nodes, and if user can share some resource, say database connection, between tasks on local node, then user will be able to share the same resource remotely without any extra deployment steps.

Groovy Examples

Release 2.1 will have changes to accommodate running GridGain from Groovy. It will also come with examples and instructions on how to run GridGain on Groovy. Overall, GridGain can work from Groovy quite naturally, we just had to make a few small changes to make sure that Peer-Class-Loading works as desired.

Maven Repository

And last but not least, for all those users who keep asking about Maven repository, I am happy to announce that GridGain 2.1 will have it.