Mingfai Ma was nice enough to create GridGain Plugin for Grails. GridGain could always be run from Groovy. GridGain 2.1 will actually ship with a set of Groovy examples. I am pleased that now you can just use GridGain with Grails by simply installing the plugin.

For more information visit Grails - GridGain Plugin on Grails site.

Enjoy!

We are in the final pre-release week of GridGain 2.1 and are currently in extensive testing stage. GridGain has over 700 units tests which constantly get rerun every time a developer makes a commit. All of our unit tests have been passing for over a week now. I would like to share some useful points about the process that help us keep high quality standard for the GridGain project:

1. Grid-Enabled Junits.
Running over 700 tests on one box takes over 3 hours to complete. However, on our Bamboo server (the CI tool we use) we got the time of execution to about 20 minutes. This is because we are utilizing our own JUnit Integration to distribute tests between several grid nodes and run them in parallel. Basically, kind of eating our own dog food.

This 20 minute turn around is huge for us, as it allows us to catch bugs and fix them rather quickly.

2. Starting Multiple Grid Nodes From a Test Case
GridGain allows to start Multiple Grid Nodes in the Same VM (just think off the top of your head if there is another product that would let you do that). This feature allows us to start multiple grid nodes in the same JUnit test case, simulate some behavior, and validate the results.

It also makes it possible to actually run all the 700 tests in parallel just like any other standard JUnit test case. Otherwise we would have to set up several grid nodes just to run a single test case, which would significantly complicate our testing.

3. Extensive Load Testing
We have over 15 load tests that we run for over a week prior to any release. Our load tests simulate scenarios that are an order of magnitude more concurrent than you would ever see in production most likely. A good number of bugs are caught and fixed during this phase.

4. Scheduling Builds Directly From My IPhone
This one I could not resist sharing ;-) Quite often, whenever I want to schedule a manual build (the one not triggered by a commit), I do it directly from my IPhone. All I have to do is access our Bamboo test server over its web interface and click on a button. Comes in kind of handy when you need to rerun your full test suite while waiting in line for a dental appointment.

As you see, we are using many of the GridGain features ourselves. This allows us to get into the shoes of a user and address many issues that we would be blind to otherwise.

Stay tuned for GridGain 2.1 release coming shortly!

As some of you may noticed I haven't been blogging as often lately. The main reason for that is that all of us at GridGain were fully concentrated on pushing our next 2.1 release out the door. And now, as I really feel we are close (probably a week or 2 away), I would like to give some heads up on the upcoming features you will see in GridGain 2.1

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.

I am sure I am forgetting something :) In following days I will touch in more details on some of the new additions and enhancements coming in 2.1 release.