Monday, 30 March 2015

Infinispan 7.2.0.Beta2 released with better default configuration handling

We've just released Infinispan 7.2.0.Beta2 which adds better support for determining which configuration options have been defined by the user versus those options that contain default values. This is an important stepping stone in our aim to enable partial configuration overlays and proper configuration template support.

On top of that, we've added the capability for Java Hot Rod clients to recover from full cluster restarts and fixed an important topology transfer bug that lead to ArrayIndexOutOfBoundsException exceptions when applying topology changes.

Finally, in order to provide better out-of-the-box experience with Near Caches in Java Hot Rod client, we have made mandatory to define the maximum number of entries Near Caches should have. Previously, Near Caches were configured to be unbounded by default which would have resulted in memory leaks unless the client removed them by calling RemoteCache.remove() or similar. A configuration exceptions is reported now if no maximum size has been defined in the Java Hot Rod client, but the user can still provide a 0 or negative value to indicate the Near Caches should be unbounded.

For a complete list of features and bug fixes included in this release, please refer to the release notes.  

Feel free to join us and shape the future releases on our forums, our mailing lists or our #infinispan IRC channel.


Thursday, 19 March 2015

Eviction Improvements in Infinispan 7.2.0.Beta1

As many of you are most likely aware Infinispan provides a way to limit how many entries are stored in a single node's memory at a given time.  This is configurable via the eviction element in xml or EvictionConfiguraitonBuilder through the programmatic configuration.

In 7.2.0.Beta1 we have made some internal changes to our internal eviction support.  This mostly entailed moving our implementation to the new ConcurrentHashMap that was updated for Java 8.  This provides for a few new benefits and behaviors.

Long Size Support

Previously our eviction entry amount was limited to the maximum value of an int (2^31) and was always rounded up to the nearest power of 2 (ie. 100 would be changed to 128 which is 2^7).

With the new changes you can store up to a long worth of entries and it is not constrained to a power of 2.  Unfortunately Beta1 does not contain the changes to allow for a long to be configured yet, but this should be fixed before 7.2.0.Final is done.

Memory wide eviction size

The old bounded map performed it's eviction based on evicting elements stored in the same segment.  This could cause the map to evict entries before it actually hit the maximum size.  This is described in detail here.

The new ConcurrentHashMap for Java 8 automatically resizes its number of segments.  As such the old method of eviction will not work.  Instead we keep track of all entries in the entire map and only evict when we go over the max size.  This prevents entries from being evicted that may not be the the least recent (previously in the case of when many elements in the same segment were added).

Better scalability

Since we utilize the new ConcurrentHashMap this automatically resizes the segments based on the amount of entries in the cache.  Increasing the number of segments has some various benefits.

Less blocking

With more segments, that means there is more fine grained locking when updating an entry.  The determination whether an entry needs evicting is done outside of any lock, further reducing contention.

Lower time complexity

Since there are more segments there should be fewer hash collisions, which should provide O(1) complexity much more frequently for accessing a given key.



Tuesday, 17 March 2015

Infinispan 7.2.0.Beta1 released

Dear Infinispan community,

We are proud to announce the release of Infinispan 7.2.0.Beta1 today.

Along the usual assortment of bug fixes, this release includes a few exciting new features:

  • Server-side scripting with JSR-223 (ISPN-5013)
  • Initial support for the JCache API over HotRod (ISPN-4955)
  • Improved size-based eviction, implemented on top of Doug Lea's ConcurrentHashMapV8 (ISPN-3023)

For a complete list of features and bug fixes included in this release, please refer to the release notes.  

Feel free to join us and shape the future releases on our forums, our mailing lists or our #infinispan IRC channel.

Many thanks to everyone who contributed to this release!

Friday, 13 March 2015

Infinispan on Openshift v3

Openshift v3 is the open source next generation of Paas, where applications run on Docker containers and are orchestrated/controlled/scheduled by Kubernetes.

In this post I'll show how to create an Infinispan cluster on Openshift v3 and resize it with a snap of a finger.

Installing Openshift v3


Openshift v3 has not been released yet, so I'm going to use the code from origin.
There are many ways to install Openshift v3, but for simplicity, I'll run a full multinode cluster locally on top of VirtualBoxes using the provided Vagrant scripts.

Let's start by checking out and building the sources:

To boot Openshift, it's a simple matter of starting up the desired number of nodes:

Grab a beer while the cluster is being provisioned, after a while you should be able to see 3 instances running:


Creating the Infinispan template

The following template defines a 2 node Infinispan cluster communicating via TCP, and discovery done using the JGroups gossip router:

There are few different components declared in this template:

  • A service with id jgroups-gossip-service that will expose a JGroups gossip router service on port 11000, around the JGroups Gossip container
  • A ReplicationController with id jgroups-gossip-controller. Replication Controllers are used to ensure that, at any moment, there will be a certain number of replicas of a pod (a group of related docker containers) running. If for some reason a node crashes, the ReplicationController will instantiate a new pod elsewhere, keeping the service endpoint address unchanged.
  • Another ReplicationController with id infinispan-controller. This controller will start 2 replicas of the infinispan-pod. As it happens with the jgroups-pod, the infinispan-pod has only one container defined: the infinispan-server container (based on jboss/infinispan-server) , that is started with the 'clustered.xml' profile and configured with the 'jgroups-gossip-service' address. By defining the gossip router as a service, Openshift guarantees that environment variables such as JGROUPS_GOSSIP_SERVICE_SERVICE_HOST are available to other pods (consumers).

Applying the template

To apply the template via cmd line:

Grab another beer, it can take a while since in this case the docker images need to be fetched on each of the minions from the public registry. In the meantime, to inspect the pods, along with their containers and statuses:

Resizing the cluster

Changing the number of pods (and thus the number of nodes in the Infinispan cluster) is a simple matter of manipulating the number of replicas in the Replication Controller. To increase the number of nodes to 4:

This should take only a few seconds, since the docker images are already present in all the minions.

And this concludes the post, be sure to check other cool features of Openshift in the project documentation and try out other samples.