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

Yes, with the async client it should be clear.  If you get a delivery token back from the publish method, then the message was persisted.

I'll raise a bug for the sync client.

Ian

On 01/25/2015 09:49 AM, Davy De Waele wrote:
Perhaps the async java client can be more helpful because there you get a IMqttDeliveryToken from the publish method allowing you to do some bookkeeping (combined with the deliveryComplete callback).
I'm doing some testing with that now.

What we're currently doing (with the sync client) is simply persisting / re-delivering every message in the app itselfs when an exception occurs. 
In 95% of the cases we've got things covered, as we will be dealing with some kind of disconnect and the app will be the one doing the persisting (and not paho). However in some cases you'll have both the app and paho persisting messages, resulting in duplicates, even for QoS 2 messages.

With the sync client I don't think it's possible to design a solution that is 100% failsafe with QoS 2 (guarantied delivery AND ensuring the message is only sent once).  

Regards,
Davy

On Sun, Jan 25, 2015 at 1:10 AM, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
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


_______________________________________________
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



_______________________________________________
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