Hello
I'm looking at MQTT for a way to reliably deliver messages
between brokers (both directions), with message queuing when
the connection goes down. From other threads I read this is is
a covered use case, but I haven't found a way to configure it
correctly so some guidance would be helpful.
Scenario: server and clients run each a local MQTT broker
(mosquitto). Brokers in the clients are configured as bridges,
connecting to the server. Client configuration is below:
connection bridge_123
clientid client_123
address localhost:1883
topic mosquittodemo/test both 2
cleansession false
The broker in the server is not configured as bridge.
Server and clients can go offline at any time, and messages
should be queued locally when the connection is down. Messages
are sent in both directions. The server sends messages to a
given client by publishing on a topic only the client is
listening (not in the config above).
I'm running a server and client on different ports to test
the queuing when the connection is down. Then there are these
two cases:
1. I kill the broker on the server, and continue sending
messages to the client broker (which are queued). Then I
restart the broker on the server, and after the bridge is
reestablished the queued messages are delivered. So queuing
works when sending messages client -> server.
2. I kill the broker on the client, and continue sending
messages to the server broker (which should get queued). Then
I restart the broker on the client. The bridge is
reestablished but the old messages are not delivered. New
messages are delivered as expected.
So it seems the queuing is not working on the other side of
the bridge, on the broker that was not configured as a bridge.
Is my configuration wrong? Is this use case supported? Or
is my way of testing (killing brokers with kill -9 to simulate
a broken connection) that is not appropriate?
If it matters: I'm using mosquitto_sub and mosquitto_pub to
publish and subscribe to topics.
Thank you,
Marcelo
