GridGain 2.1 Preview
Join the DZone community and get the full member experience.Join For Free
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) &&
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.
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.
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.
Opinions expressed by DZone contributors are their own.