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 notes. Visit 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.

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.

Cheers,
Galder

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:

	<?xml version="1.0" encoding="UTF-8"?>
	<features>
	<feature name="hotrod-client" version="7.0.0.Alpha1">
	<bundle>mvn:org.jboss.logging/jboss-logging/3.1.2.GA</bundle>
	<bundle>mvn:org.infinispan/infinispan-commons/7.0.0.Alpha1</bundle>
	<bundle>mvn:commons-pool/commons-pool/1.6</bundle>
	<bundle>mvn:org.jboss.marshalling/jboss-marshalling-osgi/1.4.2.Final</bundle>
	<bundle>mvn:org.infinispan/infinispan-client-hotrod/7.0.0.Alpha1</bundle>
	</feature>
	<feature name="hotrod-client-with-query" version="7.0.0.Alpha1">
	<feature version="7.0.0.Alpha1">hotrod-client</feature>
	<bundle>mvn:org.infinispan/infinispan-query-dsl/7.0.0.Alpha1</bundle>
	<bundle>mvn:com.google.protobuf/protobuf-java/2.5.0</bundle>
	<bundle>mvn:org.infinispan/infinispan-remote-query-client/7.0.0.Alpha1</bundle>
	<bundle>mvn:org.infinispan.protostream/protostream/1.0.0.Final</bundle>
	</feature>
	</features>

view raw hotrod_feature_file.xml hosted with ❤ by GitHub

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:

	karaf@root> features:addUrl mvn:org.infinispan/infinispan-client-hotrod/7.0.0.Alpha1/xml/features
	karaf@root> features:install hotrod-client
	karaf@root> list
	START LEVEL 100 , List Threshold: 50
	ID State Blueprint Level Name
	[ 316] [Active ] [ ] [ 80] JBoss Logging 3 (3.1.2.GA)
	[ 317] [Active ] [ ] [ 80] Infinispan Commons (7.0.0.Alpha1)
	[ 318] [Active ] [ ] [ 80] Commons Pool (1.6.0)
	[ 319] [Active ] [ ] [ 80] JBoss Marshalling OSGi Bundle (1.4.2.Final)
	[ 320] [Active ] [ ] [ 80] Infinispan Hot Rod Client (7.0.0.Alpha1)
	karaf@root> features:install hotrod-client-with-query
	Refreshing bundles org.infinispan.client-hotrod (320)
	karaf@root> list
	START LEVEL 100 , List Threshold: 50
	ID State Blueprint Level Name
	[ 316] [Active ] [ ] [ 80] JBoss Logging 3 (3.1.2.GA)
	[ 317] [Active ] [ ] [ 80] Infinispan Commons (7.0.0.Alpha1)
	[ 318] [Active ] [ ] [ 80] Commons Pool (1.6.0)
	[ 319] [Active ] [ ] [ 80] JBoss Marshalling OSGi Bundle (1.4.2.Final)
	[ 320] [Active ] [ ] [ 80] Infinispan Hot Rod Client (7.0.0.Alpha1)
	[ 321] [Active ] [ ] [ 80] Infinispan Query DSL API (7.0.0.Alpha1)
	[ 322] [Active ] [ ] [ 80] Protocol Buffer Java API (2.5.0)
	[ 323] [Active ] [ ] [ 80] Infinispan Remote Query Client (7.0.0.Alpha1)
	[ 324] [Active ] [ ] [ 80] ProtoStream - core (1.0.0.Final)

view raw hotrod_installation_karaf.sh hosted with ❤ by GitHub

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 https://issues.jboss.org/browse/ISPN-4011), 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.

Cheers,

Martin

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.

	@Listener(clustered = true)
	protected static class ClusterListener {
	List<CacheEntryEvent> events = Collections.synchronizedList(new ArrayList<CacheEntryEvent>());
	@CacheEntryCreated
	@CacheEntryModified
	@CacheEntryRemoved
	public void onCacheEvent(CacheEntryEvent event) {
	log.debugf("Adding new cluster event %s", event);
	events.add(event);
	}
	}
	public void addClusterListener(Cache<?, ?> cache) {
	ClusterListener clusterListener = new ClusterListener();
	cache.addListener(clusterListener);
	}

view raw SimpleExample.java hosted with ❤ by GitHub

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.

	/**
	* Defines whether the annotated listener is clustered or not.
	* Important: Clustered listener can only be notified for @CacheEntryRemoved, @CacheEntryCreated and
	* @CacheEntryModified events.
	*/
	boolean clustered() default false;
	/**
	* If set to true then the entire existing state within the cluster is
	* evaluated. For existing matches of the value, an @CacheEntryCreated event is triggered against the listener
	* during registration. If this is a local listener only the current node state is evaluated. Only in a cluster
	* listener is the entire state sent back.
	* <p>
	* <b>Currently this is not supported!</b>
	**/
	boolean includeCurrentState() default false;

view raw Listener.java hosted with ❤ by GitHub

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

KeyValueFilter

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.

	package org.infinispan.notifications;
	import org.infinispan.metadata.Metadata;
	/**
	* A filter for keys with their values.
	*
	* @author William Burns
	* @since 7.0
	*/
	public interface KeyValueFilter<K, V> {
	/**
	* @param key key to test
	* @param value value to use (could be null for the case of removal)
	* @param metadata metadata
	* @return true if the given key is accepted by this filter.
	*/
	boolean accept(K key, V value, Metadata metadata);
	}

view raw KeyValueFilter.java hosted with ❤ by GitHub

Converter

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.

	package org.infinispan.notifications;
	import org.infinispan.metadata.Metadata;
	/**
	* Converter that can be used to transform a given entry to a different value. This is especially useful to reduce
	* overall payload of given data that is sent for the given event when a notification is send to a cluster listener as
	* this will have to be serialized and sent across the network when the cluster listener is not local to the node who
	* owns the given key.
	*
	* @author William Burns
	* @since 7.0
	*/
	public interface Converter<K, V, C> {
	C convert(K key,V value, Metadata metadata);
	}

view raw Converter.java hosted with ❤ by GitHub

Cache

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.

	/**
	* Registers a listener that will be notified on events that pass the filter condition. The value presented in the
	* notifications will be first converted using the provided converter if there is one.
	* @param listener The listener to callback upon event notifications. Must not be null.
	* @param filter The filter to see if the notification should be sent to the listener. Can be null.
	* @param converter The converter to apply to the entry before being sent to the listener. Can be null.
	* @param <K> The type of the key
	* @param <V> The type of the Value
	* @param <C> The type of the resultant value after being converted
	* @throws NullPointerException if the specified listener is null
	*/
	<K,V,C> void addListener(Object listener, KeyValueFilter<K, V> filter, Converter<K, V, C> converter);

view raw FilteringListenable.java hosted with ❤ by GitHub

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.

Events

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 will be true if the write command that caused this had to be retried again due to a topology change. This
	* could be a sign that this event has been duplicated or another event was dropped and replaced
	* (eg: ModifiedEvent replaced CreateEvent)
	* @return Whether the command that caused this event was retried
	*/
	boolean isCommandRetried();

view raw CacheEntry*Event.java hosted with ❤ by GitHub

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.

Infinispan HotRod C# Client 7.0.0.Alpha1 release

Infinispan HotRod C# Client 7.0.0.Alpha1 is now available. This new version is a C# wrapper over the native client and brings support for L2 and L3 client intelligence levels in addition to L1. As more features are added to the native client they will make their way into the C# client as well.

You can find the the .msi installer on the download page and the source code on GitHub.
Please give it a try and let us know what you think.