New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
giorver opened this Issue Nov 15, 2018 · 5 comments

Comments

Projects
None yet
2 participants
@giorver
Copy link

giorver commented Nov 15, 2018

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 ralight added this to the 1.5.5 milestone Nov 20, 2018

@ralight

This comment has been minimized.

Copy link
Contributor

ralight commented Dec 4, 2018

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

This comment has been minimized.

Copy link

giorver commented Dec 4, 2018

@ralight

This comment has been minimized.

Copy link
Contributor

ralight commented Dec 4, 2018

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

ralight added a commit that referenced this issue Dec 4, 2018

Fix outgoing retained messages not being sent by bridges.
This now happens on initial connection, after CONNACK is processed,
before it was happening (and being dropped) before the connection was
made.

Closes #1040. Thanks to giover.

Bug: #1040
@ralight

This comment has been minimized.

Copy link
Contributor

ralight commented Dec 8, 2018

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

@ralight ralight closed this Dec 8, 2018

@giorver

This comment has been minimized.

Copy link

giorver commented Dec 8, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment