Friday, 11 April 2014

Clustered cache quickstart updates

As developers, it's always easy for us to "forget" about documentation and tutorials, and let them get out of date. And this is exactly what happened with our clustered cache tutorial.

Even though we kept updating the tutorial to use the latest configuration style, the core of the tutorial was still assuming that state transfer was disabled by default - something that we changed back in Infinispan 5.0.0.Final.

This was causing a bit of confusion, so I'm happy to report that I've updated the tutorial and I've removed all traces of the ClusterValidation class. Now the tutorial allows you to start as many nodes as you want, and it also shows how a joining node receives data from the existing members during startup.

Infinispan Security #1: Authorization

Dear all, with the release of 7.0.0.Alpha3, Infinispan has finally gained the ability to perform Access Control (aka Authorization) on CacheManagers and Caches. This is the first stepping-stone towards the full-fledged security work that will be completed during the 7.0 cycle.

Infinispan authorization is built around the standard security features available in a JDK near you, such as JAAS and the SecurityManager. Here's a worked example.

Running within a SecurityManager

In order for Infinispan to be able to enforce access restrictions, you should enable the SecurityManager in your JVM. This can be done from the command-line:

java ...

or programmatically:

System.setSecurityManager(new SecurityManager());

You don't have to use the default implementation that comes with the JDK, but if you do you need to supply an appropriate policy file. The Infinispan distribution comes with an example policy file which illustrates the permissions required by some of Infinispan's JAR files. Integrate these permissions with the ones required by your application.

While Infinispan's authorization can work without a SecurityManager for the basic cache operations (put, get, etc), some more complex tasks (distexec, map/reduce, query) will fail without one.

Configuring Infinispan for authorization

Authorization in Infinispan is configured at two levels: at the cache container and at the single cache.
Let's look at cache containers (aka CacheManagers) first:
Each cache container determines the following:
  • whether to use authorization, via the enabled attribute. 
  • a class which will map the user's principals to a set of roles
  • a set of named roles and the permissions they represent
We then need to define the specific roles for each cache:

As you can see you can choose to use only a subset of the roles defined at the container level.

Before you can start using a secured cache, you need to get yourself a

Obtaining a Subject

Infinispan is not fussy about how you obtain a JAAS Subject: you may use your container's features, or a third-party library (such as JBoss PicketBox or Apache Shiro). The important thing is that your Subject should be populated with a set of Principals which represent the user and the groups it belongs to in your security domain (e.g. LDAP, Active Directory, etc).
It is then the duty of the mapper to look through the principals associated with the Subject and convert them into roles suitable for matching those you have defined at the container level.
Once you have a Subject, you interact with the Cache within the context of a PrivilegedAction as follows:

Obviously if you're lucky enough to use Java 8, you can use the following, more concise, lambda-enabled code:

For more details consult the Security chapter in the Infinispan documentation and the JavaDocs.

Stay tuned for the next parts in the Infinispan security saga !

Infinispan 7.0.0.Alpha3 is out!

The Alpha3 release of Infinispan 7.0.0 is now available.


  • authorization at both CacheManager and Cache levels
  • some important enhancements for Map/Reduce's usability, like the ability to use an intermediate cache during Map/Reduce execution and for storing the final results of the Map/Reduce tasks
  • a much welcomed revamp of the Infinispan embedded configuration which has been aligned to with the server
For a complete list of features and bug fixes included in this release please refer to the release notesVisit our downloads section to find the latest release.

If you have any questions please check our forums, our mailing lists or ping us directly on IRC.


Thursday, 27 March 2014

Infinispan 7.0.0.Alpha2 release

Dear Infinispan community,
The Alpha2 release of Infinispan 7.0.0 is now available.

This release brings Cross-Site Replication State Transfer in a stable topology (i.e. no nodes leaving or joining during the state transfer) and several bug fixes.

For a complete list of features and bug fixes included in this release please refer to the release notesVisit our downloads section to find the latest release.

Note: The LevelDB and Rest Cache Store artifacts published to the Maven repo for this version are broken. Please wait for the next Alpha release if you plan to use them. Sorry for the inconvenience.

If you have any questions please check our forums, our mailing lists or ping us directly on IRC.

Wednesday, 19 March 2014

Infinispan 6.0.2.Final includes ASL2-licensed JBoss Marshalling

We've just released Infinispan 6.0.2.Final to address a licensing issue we were having with JBoss Marshalling. Infinispan switched to ASL2 license when Infinispan 6.0.0 was released, but one of its dependencies, JBoss Marshalling, was still licensed under LGPL. JBoss Marshalling 1.4.4.Final, included in Infinispan 6.0.2.Final, has been licensed under ASL2.

The release can be found in the usual places.


Thursday, 6 March 2014

HotRod client in OSGi

Infinispan 7.0.0.Alpha1 makes it possible to easily run the HotRod client in an OSGi based container such as Karaf. Until this point there was no easy way to find out which libraries were required for the HotRod client to run in OSGi. These libraries then had to be installed manually and dynamic imports enabled for all the libraries. Last but not least, it was not possible to use the latest HotRod feature - remote queries.

The 7.0.0.Alpha1 introduces a "features" file which not only lists all dependencies required for correct functionality of the HotRod client in OSGi, but also makes it very easy to install the whole feature into Karaf (version 2.3.3 or 3.0) in just a few steps.

HotRod client feature file for OSGi

The feature file has been deployed into JBoss Nexus repository so it's publicly available. It looks like this:

Installing the HotRod client feature in Karaf

The HotRod feature (either a simple HotRod client or HotRod client with remote query capabilities) can be installed in Karaf in the following steps:

There's still one limitation with respect to remote querying, though. The remote query feauture requires a JMX-based connection to Infinispan server in order to be able to register a .protobin file, which holds the description of data types being transferred between the client and server. Since a remoting-jmx protocol is required and the existing remoting-jmx client does not work correctly in OSGi (see, it is required to register the .protobin file in another way - not from inside the OSGi container. This will be fixed in one of the next releases.

Stay connected for news about running the whole Infinispan datagrid in OSGi, not only the HotRod client. This is work in progress.


Wednesday, 5 March 2014

Embedded Cluster Listeners in Infinispan 7.0.0.Alpha1

If you are following on the dev listing, you may have seen a design doc come through that details adding support for Clustered Listeners to Infinispan.  This features allows for listeners to be used in a distributed cache configuration.  I am happy to say that this feature is now in Infinispan 7.0.0.Alpha1 !

This feature is needed since local listeners in a distributed cache are only notified of events on the node where the data resides.  Therefore, clustered listeners allow for a single listener to receive any write notification (limited to CacheEntryCreatedEvent, CacheEntryModifiedEvent and CacheEntryRemovedEvent) that occurs in the cluster which is installed on 1 node.

Basic Example

Using a cluster listener is just as easy as a regular listener. Here is a simple use case that stores the events as it receives them. That is all that is required is just to set the property of your Listener annotated class to say clustered = true. There are other important changes in the rest of the document. Please let us know how you like the new cluster listeners ! Also if any issues are found, it is much appreciated to log those to JIRA.

Differences between Local and Cluster Listeners

Pre and post Notifications

In a local cluster listener, the listener is notified twice, before the operation is completed and after the entry is updated.  A cluster listener is ONLY notified after the operation is completed while still holding locks.  Therefore, the isPre method always returns false in a cluster listener.

Transaction begin and completion

In a transactional cache, local listeners are notified when a transaction begins and when it is completed (either through rollback or commit).  A cluster listener is never notified of anything occurring until after the data has been updated, and thus will only ever be notified of committed entries and also will not receive TransactionRegisteredEvent or TransactionCompletedEvent events.

API Changes

There are a few new API classes that have been added to allow for configuration and operation of cluster listeners.

Listener annotation

The existing org.infinispan.notifications.Listener annotation has had a couple properties added to it.
The new clustered property defines whether or not this listener is a cluster listener or not.  This means the listener will be sent all write modification events.

A cluster listener is not supported in an Invalidation cache.  Local or replicated caches can use a cluster listener though.  They will behave like a local cluster listener, except that replicated will be less performant.

The includeCurrentState property is also new and will provide a way for a listener when being registered to immediately be sent a CacheCreatedEvent for every entry in the cache.  This will be supported for both local and cluster listeners.  In a local listener it will only query the local data that is available, so in the case of a Distributed cache this will still only provide a possible subset of data.  However a clustered listener will retrieve the data from all nodes as needed.  A cache will still be available for writes during the includeCurrentState period.  However the notifications will be queued until all state has been first sent. NOTE: includeCurrentState is currently not implemented but is planned during this release still see ISPN-4068


This is a new Filter class that can be used to filter events or other operations based on the key value and metadata of the updated object.


A converter is used to convert a given key, value, metadata entry to a resulting value. This is useful if your listener doesn't require the entire value and need just a portion from it. Or if the listener were to do some sort of translation, this would allow it to scale to each node instead of having to run the translation all on the node where the listener is registered.


The cache interface also has an additional overloaded method to allow for registering the previously mentioned KeyValueFilter and Converter with the Listener provided.  Note that either type of listener, cluster or local, may be used with any of the overloaded addListener methods on the Cache interface.
This new method is similar to the other addListener methods, but is specially optimized for use with cluster listeners in distributed mode. Whenever a modification occurs which would cause an event to be sent to the cluster notifier the KeyValueFilter is first ran to see if this event should even be sent to the listener. If it is then the converter will be used to convert result into whatever data is desired to send back to the listener. These combined allow for reducing overall network traffic for events that you don't want to get or reduce payload size by sending a different or subset of the value.


There are some cases in Infinispan when it is unclear if a notification was properly raised in a non transactional cache. Due to this we have made available an additional value on the CacheEntryCreatedEvent, CacheEntryModifiedEvent, and CacheEntryRemovedEvent. This is to symbolize that this event could have been possibly duplicated or even changed types (CacheEntryModifiedEvent instead of CacheEntryCreatedEvent).
This should only return true if we had a node who was an owner go down while in the middle of processing the write.

Functional Changes

CacheEntryModified during creates

Prior to Infinispan 7.0, whenever a new entry was created, this would generate both CacheEntryCreated and CacheEntryModified events.  This has been changed now so that only a CacheEntryCreated event is raised to more consistently model what has occurred.