QoS and Message Queueing on the Broker

MQTT
1

I have an edge node that implements the sparkplug B protocol. It publishes messages to DDATA topics with QoS 0. I have an MQTT client that:

  • Subscribes to the DDATA topics using QoS 1
  • Sets the clean-session flag to false (which creates a persistent session)

I’m doing some experiments using a local HiveMQ server running in a container. I connected both the publisher and subscriber clients and forced the publisher to send a few messages (BIRTH and DATA messages) and confirmed that the subscriber received them. I then disconnected the subscriber client from the broker and forced the publisher to send a few DDATA messages (at QoS 0). In the HiveMQ control interface, I inspected the subscriber client and noticed that HIveMQ reported that it has queued messages for the client. This is where I would like some clarification. I thought that messages published at QoS 0 would not be queued for delivery when a subscribed client goes offline. Am I wrong on this?

2

Hello SilaBen,

Thanks for reaching out on our HiveMQ Community Forum.

That’s correct, clients that subscribe or publish with QoS 0 do not qualify for retained/queued messages.
I’ve tested session persistence with a subscriber client with QoS 1, and a publisher client with QoS 0 in my test environment, and do not see any queued messages in my Control Center.

These are the steps I’ve performed:

  • subscribe client with QoS1 and -no-cleanStart
  • published with QoS 0
  • confirmed receipt of payload messages on the subscribe client
  • disconnected the subscribe client
  • published with QoS 0
  • Confirmed in Control Center that there are no queued messages
  • reconnected the subscribe client with Qos1 and -no-cleanStart
  • there are no retained messages to publish

Were there any steps you’ve performed that deviated from the above?
Please provide the detailed steps / MQTT client commands I can execute on my side to see if I can reproduce the issue.

Regards,
Gil

3

Hi Gil,

Thanks for looking into this. I just found my mistake. The publisher client was using QoS 1 and not QoS 0, as I mistakenly thought. Sorry for the confusion.

-Ben

4

Hello Ben,

Glad to hear you’ve identified the issue.
​If at anytime you have any questions, please don’t hesitate to reach out in our forum.

Regards,
Gil