0

Assuming I have topic A and topic B. Upon starting my application, inside on_connect, I am subscribing to both topics with QOS 2. Then I start the thread with loop_forever(). Now, lets assume I have missed messages on topic B which were sent while I was gone and I have retained messages on topic A.

Upon subscribing, which messages will be processed first?

  1. Is it defined due to the type (i.e. persistent session messages and retained messages on a topic)?
  2. Or is the subscription order in on_connect decisive? (which I would not assume as the thread starts checking them upon loop_forever() only and the order might not be presumed)
  3. Or is it random?

From my tests, it seems the missed messages I get due to the persistent session from topic B will be processed first.
Can I rely on that behaviour?

PS: As hardillb mentioned that behaviour might be broker specific. I am using Mosquitto.

lukkaz
  • 35
  • 6

1 Answers1

0

First your model is a little wrong, the client doesn't check for anything, message delivery is entirely driven by the broker. All the loop_forever() thread does is handle the inbound messages from the broker (and if needed the response for high QOS messages).

Also if you have a persistent session, then there should be no need to re-subscribe to the topics as the subscription should still be attached to the session in the broker, which will be resumed when the client reconnects (with the same client ID and cleanSession false).

As to which will be delivered first retained or queued mesages, I don't think the spec actually defines which order the broker should send queued messages vs retained messages, which means it may well be broker implementation specific.

hardillb
  • 54,545
  • 11
  • 67
  • 105
  • Yes, I see. That totally makes sense. I am using the Mosquitto broker. Do you know more specifics about this broker? – lukkaz Jun 13 '22 at 21:21
  • 1
    @lukkaz Given that the spec does not make any promises about this behavior, depending on a specific implementation to continue behaving one way is asking for trouble. You're better off rethinking why you need it to behave in a specific way and re-tooling your application to not depend on it. – romkey Jun 14 '22 at 16:08