max_queued_messages does not apply to bridge

[Andreyooo]

As stated above, if my bridge connection gets closed, messages are queued infinetly. Is this intentional behaviour?

[Andreyooo]

Also something I noticed. When clean session is set to true for the bridge, on connection-loss the broker stores additional messages up to a count of ~800, then drops them and repeats this process.

Doubling the output of messages did not change the amount of stored messages or the cycle time.

[ralight]

I suspect you are using Mosquitto 1.4.15, is that correct? The queuing behaviour did not apply to bridges a long while back but has since been fixed.

The sawtooth pattern comes about because Mosquitto is incorrectly queuing messages for the disconnected bridge, then when it tries to reconnect those messages are cleared out. I've just pushed a change to the fixes branch which should stop it doing this.

[Andreyooo]

Hey ralight, thx for your time.

I'm using mosquitto version 1.6.7, iI have set max_queued_messages 100 and clean session false for the bridge. My messages get queued infinitely. I don't have to establish a bridge connection for that. It happens even when no connection was established.

I noticed in the log the message: Outgoing messages are being dropped for client local.DDC4000.69.ddc4ke-bridge.
It get's logged once shortly before the first reconnect cycle but messages don't get dropped.

For me setting clean session to true fixes my issues, but seems still strange to me.

[ralight]

This is what I see, using 1.6.7 with max_queued_messages 100 and cleansession false.

[Andreyooo]

I see, I will play around with the settings and report back if I find out why I have different behaviour

[karlp]

You might also have some stale clients with subscriptions in your persistence db? it can very much skew things if you don't start from a clean point