Page History

...

Server:
The server processes the ack command from client and maintains it in the HARegionQueue.ackedEvents map. 

...

The event from HARegionQueue is removed based on the client acknowledgement (“HAregionQueue.remove()”).

Reliable Event Delivery:

The reliable Reliable event delivery (in case of node failure) is achieved by with subscription redundancy level. Client can configure to have queues created on multiple server nodes by setting redundancy level.

With redundancy set; the HARegionQueues are created on multiple servers; one of the queue queues is treated as primary queue and others as secondary queues.

...

The events are dispatched to clients from the primary HARegionQueue, if . If the node hosting the primary queue goes down, one of the nodes hosting secondary queue queues becomes the primary and starts dispatching the events. During this scenario it could so happen that, duplicate events are could be sent to client. At the client side checks are made for duplicate events and which are ignored.

When the message is delivered and successfully removed from the primary HARegionQueue, the acknowledgement is sent to other servers hosting the queues (“QueueRemovalMessage”).

...

When the secondary queues are created; in order to be in sync with primary queue, they perform initial data replication from one of the existing queue queues (using backing region’s GII mechanism - “HARegionQueue.createHARegion()”).

During queue initialization, If there are any events satisfying the interest criteria ; those events are queued temporarily in “CacheClientProxy.queuedEvents”, once . Once the initialization is over, the events from the temporary queue is are added to HARegionQueue for delivery.

After the events are delivered and removed from the primary queue (node), it sends the “QueueRemovalMessage” to secondary queues (nodes); as part of message processing the each secondary queue removes events from its queue(“QueueRemovalMessage.process().removeDispatchedEvents()”.

...

Based on number of client queues, and the rate at which events are delivered, the individual queues may consume lot of memory; in . In order to reduce the memory footprint the events are stored in a container (“HAContainer”) and all the client queues will refer to this instead of having their own copy (“HARegionQueue.putEntryConditionallyIntoHAContainer()”).

The reason for doing this is , that in most of the cases clients will have common interests , so having a single copy of the client message will reduce the memory significantly.

Once event is delivered to all the interested client; clients, the event is removed from HAContainer is removed (“HARegionQueue.decAndRemoveFromHAContainer()”).

Code path for adding event to HAContainer:
HARegionQueue.basicPut()->putObject()->putEventInHARegion()->putEntryConditionallyIntoHAContainer().

Event Conflation:

The clients can configure events to be conflated; in this case : the old events in the HARegionQueue will be destroyed and a new event is added to the tail of the Queue.

...