Clustering: Sending messages between cluster servers

If it is imperative that quality of service (QoS) 1 and QoS 2 messages are always received by an application, connect an instance of the receiving application with a shared MQTT subscription or as a JMS application to each server that is in the cluster.

When a message is published on a server in the cluster, it is delivered to subscribers attached to the same server and, if there are known subscribers on other servers, it is forwarded to the other servers where it is published to subscribers attached there. Subscribers on the same server receive the message immediately; subscribers on other servers receive the message at a later point when it has been forwarded to those servers.

Messages are forwarded according to the QoS that is requested at the time of publishing; QoS 0 messages are sent as quickly as possible but unreliably and QoS 1 or QoS 2 messages are sent more slowly but reliably. As messages are forwarded, a queue of such messages may build up especially if the server that they are destined for is currently disconnected.

The size of the forwarding queues is not generally limited. However, when server memory levels become low, a limit on total message data is imposed on the forwarding queues. The limit employs a mechanism similar to the DiscardOldMessages mechanism, to discard older messages until the amount of memory that the queues consume is reduced. The forwarding queue for QoS0 messages is limited first, but if the memory continues to be depleted, the queue of QoS 1 and QoS 2 messages is also limited. This can mean that, in low memory situations, QoS 1 and QoS 2 messages that are being forwarded to remote servers are discarded. If it is a requirement that QoS 1 and QoS 2 messages are always received by an application, ensure that you connect an instance of the receiving application with a shared MQTT subscription or as a JMS application to each server in the cluster.