The notify event container uses the space inheritance support for notifications using a GigaSpaces unified event session API. If a notification occurs, the data event listener is invoked with the event. A notify event operation is mainly used when simulating Topic semantics.
Here is a simple example of a notify event container configuration:
<!-- Enable scan for OpenSpaces and Spring components --><context:component-scan base-package="com.mycompany"/><!-- Enable support for @Notify annotation --><os-events:annotation-support /><os-core:space id="space" url="/./space" /><os-core:giga-space id="gigaSpace" space="space"/>
@EventDriven @Notify
public class SimpleListener {
@EventTemplate
Data unprocessedData() {
Data template = new Data();
template.setProcessed(false);
return template;
}
@SpaceDataEvent
public Data eventListener(Data event) {
//process Data here
}
}
GigaSpace gigaSpace = // either create the GigaSpace or get it by injection
SimpleNotifyEventListenerContainer notifyEventListenerContainer = new SimpleNotifyContainerConfigurer(gigaSpace)
.template(new Data(false))
.eventListenerAnnotation(newObject() {
@SpaceDataEvent
public void eventHappened() {
eventCalled.set(true);
}
}).notifyContainer();
// when needed dispose of the notification container
notifyEventListenerContainer.destroy();
The above example registers with the space for write notifications using the provided template (a Data object with its processed flag set to false). If a notification occurs, the SimpleListener is invoked. Registration for notifications is performed on the configured GigaSpace bean. (In this case, if working in a clustered topology, the notification is performed directly on the cluster member.)
Primary/Backup
By default, the notify event container registers for notifications only when the relevant space it is working against is in primary mode. When the space is in backup mode, no registration occurs. If the space moves from backup mode to primary mode, the container registers for notifications, and if it moved to backup mode, the registrations are canceled.
This mostly applies when working with an embedded space directly with a cluster member. When working with a clustered space (performing operations against the whole cluster), the mode of the space is always primary.
Template Definition
When performing receive operations, a template is defined, creating a virtualized subset of data in the space, matching it. GigaSpaces supports templates based on the actual domain model (with null values denoting wildcards), which are shown in the examples. GigaSpaces allows the use of SQLQuery in order to query the space, which can be easily used with the event container as the template. Here is an example of how it can be defined:
@EventDriven @Notify
public class SimpleListener {
@EventTemplate
SQLQuery<Data> unprocessedData() {
SQLQuery<Data> template = new SQLQuery<Data>(Data.class, "processed = true");
template.setProcessed(false);
return template;
}
@SpaceDataEvent
public Data eventListener(Data event) {
//process Data here
}
}
The notify container can be configured with transaction support, so the event action can be performed under a transaction. Exceptions thrown by the event listener cause the operations performed within the listener to be rolled back automatically.
When using transactions, only the event listener operations are rolled back. The notifications are not sent again in case of a transaction rollback. In case this behavior is required, please consider using the Polling Event Container.
Transaction support can be configured as follows:
<!-- Enable scan for OpenSpaces and Spring components --><context:component-scan base-package="com.mycompany"/><!-- Enable support for @Polling annotation --><os-events:annotation-support /><os-core:space id="space" url="/./space" /><os-core:local-tx-manager id="transactionManager" space="space"/><os-core:giga-space id="gigaSpace" space="space" tx-manager="transactionManager"/>
@EventDriven @Notify @TransactionalEvent
public class SimpleListener {
@EventTemplate
Data unprocessedData() {
Data template = new Data();
template.setProcessed(false);
return template;
}
@SpaceDataEvent
public Data eventListener(Data event) {
//process Data here
}
}
The notify container allows you to mask which operations performed against the space, should cause notifications. By default (if none is defined), notifications are sent for write operations. The operations are: write (an entry matching the template has been written to the space), update (an entry matching the template has been updated in the Space), take (an entry matching the template has been taken from the Space), lease expiration (an entry matching the template lease has been expired), unmatched (an entry matching the template no longer matches the template), and all. Here is an example of the notify container configured to trigger notifications for both write and update operations:
@EventDriven @Notify
@NotifyType(write = true, update = true)
public class SimpleListener {
@EventTemplate
Data unprocessedData() {
Data template = new Data();
template.setProcessed(false);
return template;
}
@SpaceDataEvent
public Data eventListener(Data event) {
//process Data here
}
}
unmatched Masking Notification is a New feature in XAP 6.6.0
Communication Protocol Type
The notify container, through the use of the unified event session API, can control how notifications are triggered from the space to the listener, in terms of communication protocol. The following communication protocols are available:
Communication Protocol
Description
UNICAST
Unicast propagation uses TCP unicast communication, which is usually best for a small amount of registered clients. This is the default communication type.
MULTIPLEX
The same as UNICAST in terms of communication protocol, but uses a single client-side multiplexer, which handles all of the dispatching to the different notification listeners.
MULTICAST
Multicast propagation uses UDP multicast communication, which is usually best for large amounts of registered clients. See the JavaSpaces Multicast Notifications section*** for configuration options.
Here is a sample configuration of the notify container that uses the MULTIPLEX communication protocol type:
@EventDriven @Notify(commType = NotifyComType.MULTIPLEX)
public class SimpleListener {
@EventTemplate
Data unprocessedData() {
Data template = new Data();
template.setProcessed(false);
return template;
}
@SpaceDataEvent
public Data eventListener(Data event) {
//process Data here
}
}
The JavaSpaces Multicast Notifications section*** explains how to configure and enable multicast notifications support inside the space schema. The multicast worker itself can be easily enabled in the space configuration:
OpenSpaces, through the unified event API, allows batching of notifications. Batching causes the space to accumulate the notifications, and once a certain amount of time has passed or a certain size is reached, causes the events to be raised to the client. Batching is very useful when working with a remote space, since it reduces the network roundtrip operations. Below is an example of batching, where if the number of notifications has passed 10, or the time passed is 5 seconds (since the last batch was sent), a batch of notifications is sent to the client:
@EventDriven @Notify
@NotifyBatch(size = 10, time = 5000)
public class SimpleListener {
@EventTemplate
Data unprocessedData() {
Data template = new Data();
template.setProcessed(false);
return template;
}
@SpaceDataEvent
public Data eventListener(Data event) {
//process Data here
}
}
The notify event container can register for events or notifications and have the events delivered in a FIFO order.
For full FIFO support, the actual template also has to be marked as FIFO. For more details, refer to the Space FIFO support section.
Here is an example of how FIFO events can be configured with the notify container:
@EventDriven @Notify(fifo = true)
public class SimpleListener {
@EventTemplate
Data unprocessedData() {
Data template = new Data();
template.setProcessed(false);
return template;
}
@SpaceDataEvent
public Data eventListener(Data event) {
//process Data here
}
}
The notify event container can be configured to automatically perform a take on the notification data event. It can also be further configured to filter out events if the take operation returned null. (This usually happens when several clients receive this event, and only one succeeds with the take.)
Here is how the notify container can be configured:
@EventDriven @Notify(performTakeOnNotify = true, ignoreEventOnNullTake = true)
public class SimpleListener {
@EventTemplate
Data unprocessedData() {
Data template = new Data();
template.setProcessed(false);
return template;
}
@SpaceDataEvent
public Data eventListener(Data event) {
//process Data here
}
}
When registering for notifications, using the unified event session API (or using plain notify registration), the following interface needs to be implemented:
GigaSpaces extends this interface by providing the EntryArrivedRemoteEvent, which holds additional information regarding the event that occurred. The notify container, by default, uses the EntryArrivedRemoteEvent in order to extract the actual data event represented by the event, and passes it as the first parameter. If access to the EntryArrivedRemoteEvent is still needed, it is passed as the last parameter to the space data event listener. Here is an example of how it can be used:
public class SimpleListener implements SpaceDataEventListener {
public void onEvent(Object data, GigaSpace gigaSpace, TransactionStatus txStatus, Object source) {
EntryArrivedRemoteEvent entryArrivedRemoteEvent = (EntryArrivedRemoteEvent) source;
// ...
}
}
When using the different listener adapters, such as the annotation adapter, it can be accessed in the following manner (since adapters use reflection, there is no need to cast to EntryArrivedRemoteEvent):
public class SimpleListener {
@SpaceDataEvent
public void myEventHandler(Trade data, GigaSpace gigaSpace, TransactionStatus txStatus,
EntryArrivedRemoteEvent entryArrivedRemoteEvent) {
// process event
}
}
Default Values of Notify Container Configuration Parameters
This mostly applies when working with an embedded space directly with a cluster member. When working with a clustered space (performing operations against the whole cluster), the mode of the space is always primary.
When using transactions, only the event listener operations are rolled back. The notifications are not sent again in case of a transaction rollback. In case this behavior is required, please consider using the 
unmatched Masking Notification is a New feature in XAP 6.6.0
icon).
Add Comment