Hello,
We are having a cluster of HiveMQ brokers with a load balancer in front of it and replica count > 1.
Our clients are using QoS 1 and persistent sessions. For one topic we need ordering guaranties. We have one publisher publishing on this topic, and one subscriber listening on it. This subscriber should see and acknowledge the messages in the order in which they have been published by the publisher. Duplicates of already acknowledged messages are okay.
Let’s assume for example, that the published publishes the messages in the order M1, M2, M3, M4, M5 on the same topic T. Then the subscriber should see them in that order.
To be more precise, let’s assume the subscriber has acknowledged M1 and M2 (via PUBACK) and now crashes while processing M3 before sending the PUBACK. When the client comes up again (without clearing its session), then it should receive M3 before receiving M4 and M5. It’s okay if it will receive M1 and/or M2 again before receiving M3, but in no case it should receive M4 or M5 before it has acknowledged M3.
- Is this ordering assumption correct?
- Does it hold even if the client fails?
- Does it hold in a clustered setup?
- Does it hold in a clustered setup even when the node to which the subscriber is connected fails?
I saw some conversation pointing into this direction like High Availability Cluster Support - HiveMQ Commercial Offerings - HiveMQ Support Forum, but there is also a blog post Understanding MQTT Message Ordering stating “Strict message ordering on an MQTT topic is not guaranteed in a clustered MQTT broker setup“. So, I am confused and some clarification would be helpful.
Thanks a lot in advance,
Sven