I have a number of QoS2 level messages that are causing problems in the scenario when the MQTT broker or client is having issues. These issues can include
- client has lost connectivity with the broker (internet connection down , issue with the broker, ....) for a while and reconnects.
Typically, when the MQTT client starts receiving timeouts or other errors from the broker, the message are stored in the persistence storage (in-flight messages) and will eventually get republished.
However, at some point when the connection is lost and the mqtt client is no longer connected, these messages will not be considered in-flight and will not be stored by Paho. At that point it seems that the app becomes responsible for persisting these msgs (outside of paho).
Am I correct in saying that when the MQTT broker becomes unavailable, the Paho MQTT client cannot help me out in guaranteeing that these QoS2 level messages will get redelivered ?
How should the client be programmed ?
Do need a to do my own message persistence alongside Paho based on exception codes ?
Do I need to take into account the connectionLost and assume that from that point on Paho will not persist anything for me until the MQTT Client reconnects ?
Here are some exceptions and persistence behaviour by paho
- Connection lost (32109) : message is persisted by paho
- Client is currently disconnecting (32102) : message is lost by paho
- Timed out waiting for a response from the server (32000) : message is persisted paho
- Client is not connected (32104) : message is lost by paho
Regards,
Davy
