|Re: [paho-dev] Outgoing message queue|
thank you for your fast response.
What I need is to avoid paho to store any outgoing message in case the connection is lost and be sure that, on reconnect, it never tries to send any queued message.
That would mean I can handle transmission failures using different policies depending on the type of message I was sending before failing.
An example of usefulness of such behaviour is when trying to send a "counter" value via mqtt.
Why sending old counter values, accumulated when device was disconnected, when we have the last value at disposal? We can avoid sending such data keeping low cost of data trasmissions.
One of the possibilities I'm thinking is to destroy the client, when detecting disconnection, and re-create a new client before retrying to connect again.
That would ensure the behaviour we need, but it seems to be too much drastic.
Meanwhile I'll take a look at the persistence feature you mentioned.
From: paho-dev-bounces@xxxxxxxxxxx <paho-dev-bounces@xxxxxxxxxxx> on behalf of Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
Sent: 18 January 2018 11:49:07
Subject: Re: [paho-dev] Outgoing message queue
a quick answer to your main question. There is no current way to get detailed access to the outboundMsgs list. However, all those messages are stored via the persistence interface, so you could hook into that to get the information you need. A simple
persistence mechanism is supplied so you could use that as a base.
If you use the "reliable" setting, then only the last single message is stored, and that is only for QoS 1 or 2 while the relevant MQTT packet exchange completes.
These considerations only apply assuming you are using QoS > 0 and cleansession=False, because otherwise on a network break there will be no state to continue with on reconnect.
On 17/01/2018 10:07, Denis Barbuse wrote:
-- Ian Craggs icraggs@xxxxxxxxxx IBM United Kingdom Paho Project Lead; Committer on Mosquitto
Back to the top