Showing and cleaning MQTT unconfirmed messages


#1

Table of contents

1. Introduction

Inside MQTT standard, unconfirmed messages are the following:

  • Qos1 and Qos2 messages that are in transit and haven’t received confirmation (PUBACK, PUBCOMP). That is, QoS1 and Qos2 messages that are in the process of being delivered. Once confirmation is received from peer these messages are removed.

  • Qos1 and Qos2 messages that are pending to be delivered for offline devices that subscribed in the past to matching topics. That is, a device connecting with cleanSession=false and subscribing with QoS1 or Qos2 and then disconnects, will cause messages matching these topics to be kept and pending to be delivered next time device connects.

Because Qos0 messages has no confirmation they have no retry/redeliver mechanism and thus they are never kept as unconfirmed messages pending to be delivered.

2. What happens if confirmation is not received

In such case, these messages will be kept and attempted for deliver next time device connects again.

3. How unconfirmed messages relates to skip connection replace

Because devices connecting with “skip connection replace option” will create a virtual temporal ClientId, then it is not possible for the same device to reconnect and receive those messages next time (because that clientId is temporal).

Because of that, if you enable Skip Connection Replace, no unconfirmed messages will be save to storage.

4. How to review unconfirmed messages

You can easily check current messages pending to be delivered for your domain:

  1. Go to manage your domain:

  2. Then click on unconfirmed messages:

You can also check unconfirmed messages for a particular device by clicking on it:

  1. Select device:

  2. Now click on unconfirmed messages:

5. How to remove unconfirmed messages for a device or the complete domain

  1. Use the option provided to clean unconfirmed pending messages for a particular device:

  2. Same options is available for domain level:


Connecting several devices with same credentials (how to avoid MQTT connection replace, connection replacement)