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

[Prashant Kedia <prashantkedia22@xxxxxxxxx>]

Hi,

This is how I have implemented explicit forced ping as of now.

public class EnhancedMqttClient extends MqttClient {

protected static final String TAG_CLASS_NAME = EnhancedMqttClient.class

.getName();

private ExecutorService executor;

private Object lock = new Object();

public EnhancedMqttClient(Context context, String serverURI,

String clientId, MqttClientPersistence persistence)

throws MqttException {

super(serverURI, clientId, persistence);

aClient = new MyMqttAsyncClient(serverURI, clientId, persistence);

}

public void ping() throws MqttException {

try {

executor = Executors.newSingleThreadExecutor();

executor.submit(new PingExecutor()).get(10, TimeUnit.SECONDS);

} catch (TimeoutException e) {

Log.e(TAG_CLASS_NAME, "Ping Failure - Timeout");

disconnectForcibly(1000, 1000);

} catch (InterruptedException e) {

e.printStackTrace();

} catch (ExecutionException e) {

e.printStackTrace();

} finally {

executor.shutdownNow();

}

}

private class PingExecutor implements Callable<Boolean>  {

@Override

public Boolean call() throws Exception {

MqttDeliveryToken token = new MqttDeliveryToken(getClientId());

token.setActionCallback(new IMqttActionListener() {

@Override

public void onSuccess(IMqttToken asyncActionToken) {

System.out.println("Ping Success");

synchronized (lock) {

lock.notify();

}

}

@Override

public void onFailure(IMqttToken asyncActionToken, Throwable exception) {

System.out.println("Ping Failed");

try {

if (isConnected()) {

disconnectForcibly(1000, 1000);

}

} catch (MqttException e) {

e.printStackTrace();

}

}

});

MqttPingReq pingMsg = new MqttPingReq();

((MyMqttAsyncClient) aClient).getClientComms().sendNoWait(pingMsg, token);

synchronized (lock) {

lock.wait();

}

return true;

}

}

}

There are two issues with this implementation.

1) onFailure callback MqttDeliveryToken does not gets called every time ping fails. That's why I had to implement timer here with the help of ExecutorService.

2) On failure I call disconnectForcibly. It terminates all the mqtt callback threads and disconnect client as expected, but it does not make a call to mqtt callback connectionLost as there is no cause for shutdown here.

Please let me know if there is any better way to implement the same.

On Fri, Aug 15, 2014 at 11:13 AM, Prashant Kedia <prashantkedia22@xxxxxxxxx> wrote:

Yes, It detects network connectivity changes.

On Fri, Aug 15, 2014 at 4:19 AM, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

Hi Prashant,

how will your application know when to send the ping?  Will it detect the network connectivity change?

Ian

On 08/14/2014 04:48 PM, Prashant Kedia wrote:

Here network connectivity changes means switching from wi-fi to mobile data and vice-versa. And also switching on and off internet connection on Android platform.

The issue is on Android when I disable internet connection (mobile data) connectionLost callback does not gets called even after KeepAliveTimeInterval has elapsed. And does not receive any further published message (after internet connection is back on) making the connection useless. That's why whenever network connectivity changes I want to make sure that the connection is working properly with a forced ping.

What I just observered is connectionLost does not gets called org.eclipse.paho.client.mqttv3-1.0.0 but it works fine on org.eclipse.paho.client.mqttv3-1.0.1-SNAPSHOT. Even though it is working fine on later version I need explicit ping as I don't want to keep ping interval to low value as it would consume battery on mobile and I can even afford to wait till next scheduled ping.

On Thu, Aug 14, 2014 at 8:16 PM, Bin BJ Zhang <zhbinbj@xxxxxxxxxx> wrote:

 First of all, i want to know what do you mean by network connectivity changes?
 Dose it mean the socket is closed?  if yes, i don't think you can send a ping if the tcp connection is not established.
 If the connection is broken, the MqttCallback.connectionLost callback will be called, so you can get notified. So i don't think you need
 a force ping.

The purpose of ping is keeping the connection alive if there is no activities between client and broker, and it's not a good idea to hook into the
ping internals. The ping should be transparent to users, and only the keepAlive interval the user should care about.

 FYI. the default TimerPingSender implementation is always started with a keepAlive delay.

The reason why you want a custom TimerPingSender is seems not clear to me.
 

Best Regards,
Bin Zhang(张斌)
--------------------------------------------------------------------------------------------
WebSphere MQ, IBM China Software Development Lab
-------------------------------------------------------------------------------------------

Prashant Kedia ---08/14/2014 04:57:02 PM---How it is explicitly allowed in 1.0.0? I tried MqttAsyncClient's checkPing() and ClientComms's check

From: Prashant Kedia <prashantkedia22@xxxxxxxxx>
To: General development discussions for paho project <paho-dev@xxxxxxxxxxx>

Date: 08/14/2014 04:57 PM

Subject: Re: [paho-dev] Android - Paho Mqtt client does not receive messages once network connectivity changes (mobile data disabled and enabled again)
Sent by: paho-dev-bounces@xxxxxxxxxxx

---

How it is explicitly allowed in 1.0.0? I tried MqttAsyncClient's checkPing() and ClientComms's checkForActivit()y method to implement explicit forced ping but it doesn't work. Can you please explain how to implement forced explicit ping without affecting the internal scheduled ping.

I could send explicit forced ping and get response with code below, but it is useless in case ping fails. It does not terminate connection if ping fails.

MqttDeliveryToken token = new MqttDeliveryToken(getClientId());
MqttPingReq pingMsg = new MqttPingReq();
aClient.comms.sendNoWait(pingMsg, token);

I tried to replace existing TimerPingSender with my custom TimerPingSender and disabled the first scheduled ping so as to send ping on button click, but my first ping on button click doesn't work (although it schedule next ping after keepaliveinterval).

The requirement is, whenever network connectivity changes, I want to send an explicit forced ping to ensure the connection is live and I am able to receive message with same connection. If not it should terminate existing connection and I will reconnect then.


On Wed, Aug 13, 2014 at 8:32 PM, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

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



_______________________________________________
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
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

_______________________________________________
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

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 Kedia

Co-Founder and Developer

Bizlers Technologies Pvt. Ltd.

--

Thanks and Regards,

Prashant Kedia

Co-Founder and Developer

Bizlers Technologies Pvt. Ltd.