Re: [paho-dev] Android - Paho Mqtt client does not receive messages once

[Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>]

Prashant,

I answered the stack overflow question.

1) org.eclipse.paho.client.mqttv3 (version 1.0.0) is just a newer version of mqtt-client (version 0.4.0).  I thought that maybe we should remove 0.4.0 to void confusion. 

We weren't aware that any version of the Paho Java client was available in Maven Central.  There appears to be an mqtt-client package there but it's from fusesource, not Paho.

2) A colleague of mine Al, who has worked on the Java client says "interesting that he was implementing his own ping method in 0.4, although that is explitictly allowed in 1.0.0 as we added that as an interface"

Ian

On 08/13/2014 08:05 AM, Prashant Kedia wrote:

Thanks Ian, that was helpful.

I did ask the same question at stackoverflow. Can you put your answer here so that other might be able to use it in future.

Beside this, I have few more questions.

1) There are two projects for Mqtt Client, provided here.

i) mqtt-client (version 0.4.0)

ii) org.eclipse.paho.client.mqttv3 (version 1.0.0)

What is the difference between the two. If it's just different versions of same APIs why 1.0.0 is not available in Maven Central Repository.

Actually till now I was using 0.4.1-SNAPSHOT through maven central repository but now I want to switch to version 1.0.0.

2) In class MqttClient data member MqttAsyncClient has been declared as protected in version 0.4.0 and 1.0.0 but in 0.4.1-SNAPSHOT it is declared as private which does not allow us to overwrite the class to implement explicit ping. Why it is so? Is there any chance it would be private again in future release? Because if that is the case, I will have to change my implementation with the new release of Paho API.

On Tue, Aug 12, 2014 at 2:33 AM, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

The Java client is at the mercy of the underlying networking API to a certain extent.  When publish is called, it will write an MQTT packet to the socket.  If that write fails, then connection lost will be called, if that write works then the client library will carry on.  The difference in behaviour you are seeing is because the networking libraries are behaving differently in these circumstances. 

Keepalive is meant to help with this.  Under certain circumstances a TCP connection may appear to be live when it is not.  This is especially possible on mobile or satellite connected devices - you can't expect the networking APIs to work exactly the same in all circumstances.  Keepalive sends a ping packet to the server and expects a response - if that response is not received, the session is assumed to be closed.

If you set the keepalive interval to say 10 seconds, then the connection should be recognised as broken within 15 to 20 seconds.

Ian

On 08/10/2014 06:09 PM, Prashant Kedia wrote:

Anyone any luck on this? 

Nagesh,

Keeping KeepAliveInterval to 5 with debug logging did not provide any clue.

I have never used it but can anyone tell me if the issue the issue is reproducible with Paho Android Service interface? If it is not, then I would go through its code to identify how it is implemented and how the issue has been handled in it.

On Sat, Aug 9, 2014 at 1:39 AM, Prashant Kedia <prashantkedia22@xxxxxxxxx> wrote:

Ian, 

Upgrading to latest version did not make any difference.

>> we could remember the subscriptions and remake them in the case of reestablishment of a broken connection.

The connection is not broken in this case as KeepAliveInterval is high (I don't even want it to break). I want to receive the messages without  connection being lost and reestablished again, as it is working with pure java.

Nagesh,

Will run your suggested test case and will provide you with results.

On Sat, Aug 9, 2014 at 12:42 AM, ನಾಗೇಶ್ ಸುಬ್ರಹ್ಮಣ್ಯ (Nagesh S) <nageshblore@xxxxxxxxx> wrote:

As a test case, could you do the following with your pure Java sample, please ?

1. Keep the keepAlive very low, say, 5 seconds.

2. Use the mosquitto broker on your desktop with debug turned on.

3. Do your connect and disconnect. You should see a sequence of CONNECT, CONNACK and other messages. That should provide a hint.

I am trying to establish the behavior of MQTT connect/disconnect and the network layer connect/disconnect.

_______________________________________________
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

--

Thanks and Regards,
Prashant Kedia

--

Thanks and Regards,

Prashant Kedia

Co-Founder and Developer

Bizlers Technologies Pvt. Ltd.

_______________________________________________
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
Committer on Paho, 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

--

Thanks and Regards,
Prashant

_______________________________________________
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
Committer on Paho, Mosquitto