Hi Everyone,
I have been doing some extensive trials with an experimental mosquitto cluster running on docker containers, and so far I am very happy with the results, except for one thing which I'm hoping one of you can help me with.
So, the cluster is quite simple and it's built like this
[Mosquitto Sync]
| | |
[M1] [M2] ... [Mn]
| | |
[HAProxy Load Balancer]
M1 to Mn connect to Mosquitto Sync via the following bridge configuration:
# ___ _ _
# | _ )_ _(_)__| |__ _ ___
# | _ \ '_| / _` / _` / -_)
# |___/_| |_\__,_\__, \___|
# |___/
connection bridge-to-sync
# REMOTE BROKER
address mosquitto-sync:1883
remote_username CLUSTER
remote_password 1234
# LOCAL BROKER
local_username ADMIN
local_password 1234
# OPTIONS
cleansession true
try_private true
bridge_attempt_unsubscribe false
notifications false
# TOPIC MAPPINGS
topic # both 2
Using the topic # both 2 mapping together with try_private true I managed to have all cluster instances share all in/out messages, as if they were a single broker entity, without any topic pre/sufixing.
However, when carrying out load tests (eg: 1000 clients publishing QOS2, 8 subscribing QOS2, spread equally across all cluster instances), I would suddenly get these messages:
Outgoing messages are being dropped for client cluster1
Outgoing messages are being dropped for client cluster2
...
So I guess this is down to processor constraints, and it's actually fine if there would be some message drops due to this. The bad part is that once outgoing messages start being dropped for one client/cluster instance, they are dropped permanently, until I restart Mosquitto Sync.
Does anyone know why this is happening, and if it's possible for Mosquitto Sync to start resending messages to clients once they are dropped due to high message load?
Thanks!
Pedro.
--
Pedro Avillez Mendes
