Message passing between cluster realms enables state to be maintained across the member realms. The complexity of the message passing differs somewhat depending on the scenario.

It is possible to publish to topics on either master or slave realm nodes.

If you publish to the master and subscribe from both master and slave nodes, the master will simply pass the event on to each slave for delivery with the correct event ID, and each slave will maintain the same event ID as set by the master.

When publishing to a topic on a slave node, the slave has to contact the master for the correct event ID assignment before the event is then propagated to each slave.

When using queues, the message passing is much more complex, since each read is destructive (i.e. it is immediately removed from the queue after it is delivered successfully).

Consider a situation where we have a cluster of 5 realms, and each realm has a consumer connected to a queue, somequeue. Assume we publish 2 events directly to the master realm's somequeue object.

If the first event happens to be consumed by a consumer on the master realm, each slave realm will be notified of the consumption of the event from somequeue and thus remove the event from its own local copy of somequeue.

If the next event is consumed by a consumer on some slave realm, then the slave realm will notify the master of the event being consumed. The master will update its local somequeue, and then propagate this change to all other slave realms (to update their own local copies of somequeue).

Both the Universal Messaging API and the JMS standard define transactional semantics for queue consumers which add to the complexity of the message passing. For example, a consumer may effectively roll back any number of events it has consumed but not acknowledged. When an event is rolled back, it must then be re-added to the queue for re-delivery to the next available queue consumer (which may exist on any of the slave realms). Each event that is rolled back requires each slave realm to maintain a cache of the events delivered to transactional consumers in order for the event to be effectively restored should it be required. The state of this cache must also be maintained identically by all cluster members. Once an event is acknowledged by the consumer (or the session is committed), these events are no longer available to any consumer, and no longer exist in any of the cluster member's queues.