Deprecation

This document is DEPRECATED.

Please consider any information here as out of date. DO NOT use this document.

Instead, refer to http://infinispan.org/documentation.

Please update your bookmarks accordingly.

Skip to end of metadata
Go to start of metadata

Infinispan offers a listener API, where clients can register for and get notified when events take place.  This annotation-driven API applies to 2 different levels: cache level events and cache manager level events.

Events trigger a notification which are dispatched to listeners.   Listeners are simple POJOs annotated with @Listener and registered using the methods defined in the Listenable interface.

For example, the following class defines a listener to print out some information every time a new entry is added to the cache:

For more comprehensive examples, please see the Javadocs for @Listener.

Cache-level notifications

Cache-level events occur on a per-cache basis, and is global and cluster-wide.  Examples of cache-level events are entries being added, removed, modified, etc.  These events trigger notifications to listeners registered to a specific cache.

Please see the Javadocs on the org.infinispan.notifications.cachelistener.annotation package for a comprehensive list of all cache-level notifications, and their respective method-level annotations.

Cache manager-level notifications

Cache manager-level events occur on a cache manager.  These too are global and  cluster-wide, but involve events that affect all caches created by a single cache manager.  Examples of cache manager-level events are nodes joining or leaving a cluster, or caches starting or stopping.

Please see the Javadocs  on the org.infinispan.notifications.cachemanagerlistener.annotation package for a comprehensive list of all cache manager-level notifications,  and their respective method-level annotations.

Synchronicity

By default, all notifications are dispatched in the same thread that generates the event.  This means that you must write your listener such that it does not block or do anything that takes too long, as it would prevent the thread from progressing.  Alternatively, you could annotate your listener as asynchronous , in which case a separate thread pool will be used to dispatch the notification and prevent blocking the event originating thread.  To do this, simply annotate your listener such:

Asynchronous thread pool

To tune the thread pool used to dispatch such asynchronous notifications, use the <asyncListenerExecutor /> XML element in your configuration file.

Listeners on RemoteCacheManager

At the moment there is no support for registering listeners for the RemoteCacheManager. Whenever calling one of the add/remove/getListener methods on the RemoteCacheManager an UnsupportedOperationException will be thrown. There are plans to support remote listeners in future versions; in order to be notified when this feature will be added you can watch/vote for ISPN-374.

Labels:
datagrid datagrid Delete
infinispan infinispan Delete
data_grid data_grid Delete
notification notification Delete
listener listener Delete
events events Delete
eventing eventing Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Sep 09, 2013

    Cache manager-level listeners (CacheStarted CacheStopped ViewChanged and (as of 5.0) Merged) must be added via cache.getCacheManager().addListener(....)

    (https://issues.jboss.org/browse/ISPN-735)

    As of 5.0, a @Merged callback is added to distinguish a regular view-change from a view-change due to recover-from-network-partition.

    In case of a replicated cache, at merge-time, there is no automatic state-merge, therefore, if updates happen during the network partition, different instances will have different opinions on the caches' contents. You should have a @Merged handler that takes care of merging the state somehow.

    • If each instance manages a distinct subset of the cache-keys, it's a matter of having each instance re-put its subset of the state into the cache.
    • If the cache-keys can be written by multiple instances, there's no simple fix since you don't know who owns which entry. A possible approach is documented here https://community.jboss.org/thread/222878