Scalable Events With JBoss Data Grid Pt. 1

JBoss Data Grid is not only a scalable in-memory data grid, but also have a ot of powerful features that are useful in different scenarios beyond storing data. In this series or article we will look closer Scalable Events which has multiple practical use-cases. We will see how events in data grid can be used to scale websocket or how is can be used in a event based integration scenario. First we will start with an overview event listeners in JBoss Data Grid.

Overview of Listeners

JBoss Data Grid has two main types of listeners, one is used when the data grid is running embedded with the application (also called library mode) and are simple called event listeners. The other type is used when the data grid is running in a separate process from the application (also called remote mode) and are called remote event listeners. 

One mayor difference between database triggers and remote event listeners is that in the later alternative the arbitrary code is executed on the client side instead of inside the database. 

Remote Event Listeners

Remote event listeners is a Hot Rod feature, meaning that it's designed to be used in Client/Server mode where the data grid is running in a separate process from the client. There are however also listeners in the embedded mode, but for the sake of clarity we will only focus on Remote Listeners for the reminder of this article.

The following events are supported in the Hot Rod Client:

• Cache entry created
• Cache entry modified
• Cache entry removed

Creating an event listener is quite simple and only requires two steps:

Create a Client Event Listener class

package ...;

import org.infinispan.client.hotrod.annotation.ClientCacheEntryCreated;
import org.infinispan.client.hotrod.annotation.ClientListener;
import org.infinispan.client.hotrod.event.ClientCacheEntryCreatedEvent;
import org.jboss.logging.Logger;


@ClientListener
public class MessageListener {

 private Logger logger = ...

 @ClientCacheEntryCreated
 public void handleCreated(ClientCacheEntryCreatedEvent<String> e) {
  logger.info(String.format("Received Cache Event of type %s with key %s", e.getType().toString(), e.getKey()));

 }


}

Register your event listeners with the cache,

private MessageListener messageListener;

@Inject @MessageCache
RemoteCache<String,Message> mc;

@PostConstruct
public void init() {
messageListener = new MessageListener(); 
mc.addClientListener(messageListener);

}

@PreDestroy
public void destroy() {
mc.removeClientListener(messageListener); 
mc.stop();

}

Every time this or another client to the data grid stores a new entry (i.e. using put or putIfAbsent) the MessageListener will be executed and print the log statement. 

Filtering Events

If the expected workload favors writes over reads it may be necessary to filter the events sent to the clients to prevent a large amount of excessive traffic being generated. We will cover how to filter event in a later article, but since filters are execute on the server it side it does mean that we have to deploy logic to the data grid server.

Customizing Remote Events

For performance reasons events default only contains the key and the type of event  (created, modified or removed). However if all events consumed will make use of the value it it might be more efficient to also include the value of the event. Be aware that the custom event has a bigger event payload compared with default events.

In the next part we will look closer at example use-cases where scalable events can be used.