Clustering: In a request-response model

It is best practice when you are using a request-response model for the requester to either use a durable response subscription established before any requests are made, by using cleanSession=false, or for cleanSession=true clients, by leaving time after subscribing before sending requests.

When an MQTT client connects to an Eclipse Amlen server in a cluster and starts to subscribe to, or consume from, a topic by using a non-shared subscription, the fact that this subscription now exists on the server is added to the information that is flowed around the cluster. If this is the first such subscription on the topic, the information is sent to other servers in the cluster.

The subscription is made immediately without the need to wait for confirmation from all other servers that they know about the subscription; the sending of confirmation takes a short time. Servers that are disconnected at the time that the subscription is made are notified of the new subscription when they become active.

Servers in the cluster do not route messages that are published on the topic to the server on which the subscription was made until they receive this updated information. The amount of messaging traffic that is sent around the servers in a cluster is, consequently, limited to that which is actually of interest to clients subscribing at those servers.

When an MQTT application subscribes while it is connected to a server, messages that are published on other servers are not delivered until the subscription information has been received at the other servers. As a result, it is not advisable for request-response applications to work with a responding application by using a non-shared MQTT subscription on a different server in the cluster.