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
