Re: [mosquitto-dev] Weird? behavior of QoS 1 with retention

[Roger Light <roger@xxxxxxxxxx>]

Hi Abilio,

This is a "quirk" of how outgoing messages are currently handled. With
QoS 0, any outgoing messages are sent immediately to the client. With
QoS>0, we have to keep state for each outgoing message, until it is
delivered, and hence there is a limit on the number of messages
allowed per client. The quirk is because the queue limit applies also
to the situation where you make a subscription, and there are retained
messages to be delivered. In other words, Mosquitto is extremely
strict about the number of messages each client is allowed in its
queue. One solution is to raise the maximum queue limit, but it would
certainly be worth thinking about changing the queueing behaviour for
when a new subscription is made, even if this breaks the maximum queue
limit. The current behaviour is a bit unexpected.

Regards,

Roger

On Mon, 17 Aug 2020 at 17:16, Abilio Marques <abiliojr@xxxxxxxxx> wrote:
>
> Hello everyone,
>
> Recently it was brought to my attention that by retaining messages with QoS 1 and then subscribing to them with QoS 1, some messages seem to get lost (?).
>
> It happened while using libmosquitto, but is easy to reproduce with command line tools:
>
> for i in $(seq 1 200); do
>   mosquitto_pub -q 1 -r -t "test/$i" -m "hello"
> done
>
> mosquitto_sub -q 1 -t 'test/+' -v -W 1 | wc -l
>
> This yields a count of 120. Increasing the timeout makes no difference. Change the subscriber to use QoS 0, and the result is 200, proving that the messages are definitely still in the broker
>
> I realize that max_queued_messages (to e.g., 1000) changes this... But is this expected behavior?
>
> Kind regards,
> Abilio
> _______________________________________________
> mosquitto-dev mailing list
> mosquitto-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mosquitto-dev