You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My use case is to create a system whereby brokers forward messages published by a local client on a topic to any other brokers that have local clients subscribed on the same topic. Any of the subscribing clients must also be able to publish to the same topic via their local broker who then forwards the message to other brokers that have local clients subscribed on the same topic.
I have tried to get this to work using bridging between brokers but to no avail. When I publish a message an infinite loop is created between the bridged brokers.
I have tried the try_private option as the config states "this means that loop detection will be more effective" - not sure what type of loop those are, I was hoping it was the loop that I had observed.
Issue 1263 claims to have fixed it in 1.6.3 but it doesn't appear to be in 2.0.18 or it doesn't seem to be an issue. Maybe my configuration is incorrect. I have tried different configurations on the topic, including in and out QoS1&2 and on both brokers.
I would hope that brokers would be able to identify that messages have been forwarded by a broker and therefore not return the same message to source. I would hope that brokers could spot if they have previously received a message. I assume that with QoS 1&2 MQTT has a provision for identifying messages with a unique id and can track them.
Can anyone shed some light as to what is going and how to prevent these message storms? Is it still a bug, a bug at all or in MQTT bridging are brokers not able to detect messages that have already been received or where initiated by themselves?
Also, I appreciate this message might be better voiced on the Eclipse forum but, unfortunately, the registration process for the forum is broken :(
Any help would be greatly appreciated.
The text was updated successfully, but these errors were encountered:
I did try a different version of Mosquitto and had the same problem. It was tested on Ubuntu 18.04
Is it a problem of configuration?(Tested the same as @JollyOwnes posted). Or is it a misunderstanding of the concept of bridges?
Resolution obtained. This is due to a misunderstanding of how brokers work and the configuration thereof. In order to achieve the desired operation only one bridge configuration is needed instead of configuring the bridge on bother brokers.
Mosquitto 2.0.18
Hi,
My use case is to create a system whereby brokers forward messages published by a local client on a topic to any other brokers that have local clients subscribed on the same topic. Any of the subscribing clients must also be able to publish to the same topic via their local broker who then forwards the message to other brokers that have local clients subscribed on the same topic.
I have tried to get this to work using bridging between brokers but to no avail. When I publish a message an infinite loop is created between the bridged brokers.
I have tried the try_private option as the config states "this means that loop detection will be more effective" - not sure what type of loop those are, I was hoping it was the loop that I had observed.
I have read various threads #1263, #2921, https://stackoverflow.com/questions/34083003/mosquitto-mqtt-looping-on-subscribe and https://groups.google.com/g/mqtt/c/rIp1uJsT9Nk.
Issue 1263 claims to have fixed it in 1.6.3 but it doesn't appear to be in 2.0.18 or it doesn't seem to be an issue. Maybe my configuration is incorrect. I have tried different configurations on the topic, including in and out QoS1&2 and on both brokers.
listener 1883 0.0.0.0
allow_anonymous true
connection ubuntu1
address 192.168.0.74:1883
topic hello both 2
try_private true
bridge_insecure true
I would hope that brokers would be able to identify that messages have been forwarded by a broker and therefore not return the same message to source. I would hope that brokers could spot if they have previously received a message. I assume that with QoS 1&2 MQTT has a provision for identifying messages with a unique id and can track them.
Can anyone shed some light as to what is going and how to prevent these message storms? Is it still a bug, a bug at all or in MQTT bridging are brokers not able to detect messages that have already been received or where initiated by themselves?
Also, I appreciate this message might be better voiced on the Eclipse forum but, unfortunately, the registration process for the forum is broken :(
Any help would be greatly appreciated.
The text was updated successfully, but these errors were encountered: