Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Android - Paho Mqtt client does not receive messages once network connectivity changes (mobile data disabled and enabled again)

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


Inactive hide details for Prashant Kedia
                  ---08/14/2014 04:57:02 PM---How it is explicitly
                  allowed in 1.0.0? I tried MqttAsyncClPrashant 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.

Back to the top