empty retained messages published while bridged brokers disconnected are not sent when reconnected

[giorver]

Hello

I am experimenting with bridging brokers and the disconnect/reconnect behavior especially in connection to retained messages. I was trying the following procedure:
on computer 1, a broker in default configuration
on computer 2, a bridge with the following configuration:

connection mybroker
address 192.168.0.185:1883
cleansession true # I tried both with and without
topic # both 0

I had a mosquitto_sub -t "#" active both on computer 1 and 2.

With both brokers active
mosquitto_pub -r -t "mytopic" -m "mypayload" resulted (correctly) in both clients printing the message and in both brokers retaining the message.
mosquitto_pub -r -t "mytopic" -n resulted (correctly) in both clients printing the message and in both brokers cancelling the retained

when computer 2 broker down
mosquitto_pub -r -t "mytopic" -m "disconnected payload" resulted (correctly) in subscriber 1 printing the message and in broker 1 retaining the message. Pulling UP broker 2 resulted (correctly) in the retained message being propagated and retained to broker 2 and subscriber 2 printing the message.

---

when computer 2 broker down
mosquitto_pub -r -t "mytopic" -n resulted (correctly) in subscriber 1 printing the empty message and in broker 1 cancelling the retained message. Pulling UP broker 2 resulted (BUG?) in the retained message NOT CANCELLED on broker 2 (correctly cancelled on broker1 though) and subscriber 2 printing the latest retained message. The retained message was the last NON-EMPTY message sent to the topic, even if it was on broker 1 before the reconnection.

Another thing I am not sure to understand is why broker 2 had a number of old retained (defined before the bridging) that were never sent to broker 1 .

Thank you for the help.

[ralight]

There are a few points to unpick here :)

Essentially what you're seeing is the clean session = False queueing behaviour. Messages are only queued for delivery to another client (the bridge in this case) if you have connected with clean session set to false, you have subscribed with QoS>0, and the message was published with QoS>1.

In your case you are using QoS 0 messages, so nothing is queued. We don't store the absence of a retained message to send on. Essentially the bridge connecting to the broker is just a client, so why would we do that?

Using QoS>1 leads you to the situation that both brokers publish their messages (assuming you have direction both) and so they end up swapping the state of the retained message.

It's a bit of a tricky problem I admit. It should be ok with one way topics though.

[giorver]

Thank you.. food for thought. I hope the retained flag can be modelled and used as a distributed database.. else its going to be tricky. Il giorno Mar 4 Dic 2018 21:31 Roger Light <[email protected]> ha scritto:

…

There are a few points to unpick here :) Essentially what you're seeing is the clean session = False queueing behaviour. Messages are only queued for delivery to another client (the bridge in this case) if you have connected with clean session set to false, you have subscribed with QoS>0, and the message was published with QoS>1. In your case you are using QoS 0 messages, so nothing is queued. We don't store the absence of a retained message to send on. Essentially the bridge connecting to the broker is just a client, so why would we do that? Using QoS>1 leads you to the situation that both brokers publish their messages (assuming you have direction both) and so they end up swapping the state of the retained message. It's a bit of a tricky problem I admit. It should be ok with one way topics though. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1040 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Aq_Dyx5JxP_o3TO-t6igZsuUcRL7niSaks5u1tulgaJpZM4YgFXR> .

[ralight]

Indeed, the proper solution is not to do naive bridging :) I'm just looking at your final point as well.

[ralight]

Last point is fixed, I'm closing this to get ready for 1.5.5.

[giorver]

Thanks :) Il giorno Sab 8 Dic 2018 20:48 Roger Light <[email protected]> ha scritto:

…

Closed #1040 <#1040>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1040 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Aq_Dy0EjJyaVbHgez2TWFb1xkzDwZGxYks5u3BeHgaJpZM4YgFXR> .