Skip to main content

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

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




Back to the top