Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] R: Paho Java Client retransmission implementation

> Would I wait forever? Unacknowledged messages will stay forever in internal in-memory queues and persistence?

With that code, yes you would wait forever. There is also
token.waitForCompletion(timeout) if you want to block for a certain
period before moving on, however that still leave the message in an
indeterminate state and unable to be resent.

> I might want to track the in-flight messages in the application and retransmit them if they are not acknowledged by a suitable timeout.
> The spec allows for this by republishing the message using the original message ID and setting the DUP flag in the MQTT PUBLISH header.
> However this is not possible in Paho with the public API used in Sample.java.

Correct, the api does not expose that sort of republishing capability.

> Do you think it would be worthwhile to add this feature to Paho?

We quite deliberately removed message retry from the client side, but
I don't recall the full reasoning (this was >2 years ago now). That
said, it does presume you are running against a 'reliable' server,
which, in the context of WebSphere MQ, you are and that you have a
reliable TCP connection (reliable in the sense packets don't
mysteriously go missing even if the connection is fragile).

So, perhaps there is a place in for this behaviour in the client -
Dave/Ian, can you recall why we did this?


> What would be the required effort?

Obviously it depends on the approach taken - here are a couple options
off the top of my head:

1. it should be fairly straight forward to add some retry logic into
ClientState, along with a config option for a retry-timeout in
ConnectOptions. The client would then do the retrying under the
covers; the application would not need to take any further action.

2. Alternatively, the DeliveryToken object could have a method
.resend() added to it, that would resubmit the message for delivery
(with the duplicate flag set). So, if
deliveryToken.waitForCompletion(timeout) timed out, the application
could choose whether to resend the message.

Option 1 means retries will just work, Option 2 gives the application
more control, but also more responsibility.


We would also have to consider the impact on the other clients in
Paho; we want to keep them feature compatible.

Regards,
Nick



On 7 August 2012 09:36, De Alti, Cristiano
<Cristiano.DeAlti@xxxxxxxxxxxx> wrote:
> Hi Nick,
> Thanks for the quick confirm.
> I know that the spec does not require it.
> More questions:
> 1) What happens if we publish a message with QoS>0 and wait for a confirm that never comes in (taken from Sample.java):
>
>     public void publish(String topicName, int qos, byte[] payload) throws MqttException {
>
>         // Connect to the server
>         client.connect();
>         log("Connected to "+brokerUrl);
>
>         // Get an instance of the topic
>         MqttTopic topic = client.getTopic(topicName);
>
>                 MqttMessage message = new MqttMessage(payload);
>         message.setQos(qos);
>
>         // Publish the message
>         log("Publishing at: "+System.currentTimeMillis()+ " to topic \""+topicName+"\" qos "+qos);
>         MqttDeliveryToken token = topic.publish(message);
>
>         // Wait until the message has been delivered to the server
>         token.waitForCompletion();
>
>         // Disconnect the client
>         client.disconnect();
>         log("Disconnected");
>     }
>
> Would I wait forever? Unacknowledged messages will stay forever in internal in-memory queues and persistence?
>
> 2) Alternatively I might decide to not wait for completion and track the confirms asynchronously in the callback:
>         public void deliveryComplete(MqttDeliveryToken token) {
>                 // Called when a message has completed delivery to the
>                 // server. The token passed in here is the same one
>                 // that was returned in the original call to publish.
>                 // This allows applications to perform asychronous
>                 // delivery without blocking until delivery completes.
>
>                 // This sample demonstrates synchronous delivery, by
>                 // using the token.waitForCompletion() call in the main thread.
>         }
>
> I might want to track the in-flight messages in the application and retransmit them if they are not acknowledged by a suitable timeout.
> The spec allows for this by republishing the message using the original message ID and setting the DUP flag in the MQTT PUBLISH header.
> However this is not possible in Paho with the public API used in Sample.java.
>
> We currently use our own MQTT client implementation but we would like to switch to Paho because it will be actively maintained.
> However our client autonomously performs retries.
> Do you think it would be worthwhile to add this feature to Paho? What would be the required effort?
>
> Thanks,
> Ciao,
>  Cristiano
> ________________________________________
> Da: paho-dev-bounces@xxxxxxxxxxx [paho-dev-bounces@xxxxxxxxxxx] per conto di Nicholas O'Leary [nick.oleary@xxxxxxxxx]
> Inviato: martedì 7 agosto 2012 10.03
> A: General development discussions for paho project
> Oggetto: Re: [paho-dev] Paho Java Client retransmission implementation
>
> Hi Cristiano,
>
> no, the paho client does not retry unacknowledged messages (except on
> reconnect).
>
> Clients are not required to retry delivery of messages.
>
> Regards,
> Nick
>
> On 7 August 2012 08:12, De Alti, Cristiano
> <Cristiano.DeAlti@xxxxxxxxxxxx> wrote:
>> Hi,
>> Does Paho Java Client implement the retransmission of unacknowledged
>> messages sent with QoS level 1 or 2?
>> I'm browsing the code but I cannot find any references to a retry mechanism.
>>
>> Ciao,
>>  Cristiano
>>
>> _______________________________________________
>> paho-dev mailing list
>> paho-dev@xxxxxxxxxxx
>> http://dev.eclipse.org/mailman/listinfo/paho-dev
>>
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/paho-dev
>
>
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/paho-dev


Back to the top