Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] QoS level 2 messages when broker disconnects
Hi Davy,

I didn't design the Java client, but I can see how this behaviour came about, and that it can be confusing.  I assume that we are talking about the synchronous client here?  And that all these exceptions are encountered when calling publish?

The main principles are:

1) if the client API is not connected (including disconnecting) at the point at which the message is to be sent, then no attempt is made to send the message, and it is not persisted.

2) if the client API is currently connected, then the message is attempted to be sent, and it is persisted before doing so.  The connection may fail before the QoS 2 exchange completes, in which the message will be retried when the client reconnects.

but both these situations are reported as exceptions, which is unhelpful.

In the C client I follow the rules:

1) if the message is persisted, then success is returned, regardless of whether the QoS 2 exchange completes

2) the connectionLost callback is invoked if the client becomes disconnected

so you know that if you get an error, you must retry the publish call.

For the Java client we could improve the situation by:

1) only throw an exception if the message is not persisted

or

2) create a another class of exceptions which clearly showed when the message was and was not persisted, something like

MqttException superclass - message not persisted
MqttIncompleteException - message was persisted.

Anyone have any comments or other suggestions?

Note that we are planning "offline buffering" for release 1.2 in June, which would mean that the message can be persisted when the client is not connected.

Ian



On 01/23/2015 10:46 PM, Davy De Waele wrote:
Hi,

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 starts to see server timeouts
- 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


_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev

-- 
Ian Craggs                          
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto

Back to the top