Scalable Events With JBoss Data Grid Pt. 1
JBoss Data Grid is loaded with handy features. Learn more about its scalable events capabilities.
Join the DZone community and get the full member experience.
Join For FreeJBoss 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.
Published at DZone with permission of Thomas Qvarnström, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments