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)

Yes, I total agree with Ian the Ping interface is NOT well designed, and should avoid it whenever possible.

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

I think the connectionLost will be called each time the network connectivity changes, it means the socket is broken and then the ping is meaningless.
And I don't think you can reuse the previous connection.  If the socket is broken you will need to reconnect.

So, force ping is not really necessary in my opinion.


Best Regards,
Bin Zhang(张斌)
--------------------------------------------------------------------------------------------
WebSphere MQ, IBM China Software Development Lab
Notes:   Bin BJ Zhang/China/IBM
E-Mail:  zhbinbj@xxxxxxxxxx
Address: Ring Building 3F, ZhongGuanCun Software Park,

DongBeiWang West Road No.8, Haidian District, Beijing, 100193, China
-------------------------------------------------------------------------------------------


Inactive hide details for Ian Craggs ---08/17/2014 05:52:50 AM---Hi Prashant, so looking at the documentation here:Ian Craggs ---08/17/2014 05:52:50 AM---Hi Prashant, so looking at the documentation here:

From: Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
To: paho-dev@xxxxxxxxxxx
Date: 08/17/2014 05:52 AM
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





Hi Prashant,

so looking at the documentation here:
http://www.eclipse.org/paho/files/javadoc/index.html

I see that an interface MqttPingSender has been introduced to allow an application to implement its own ping strategy.  I must admit that this does not look like the sort of interface I was expecting.

Bin, Al - could you explain to me how this is supposed to be used?  Naively I might have expected a method called Ping() in the client API where additional pings could be sent by the application as required.  Is anything more than this really necessary?

Ian

On 15/08/14 21:42, Prashant Kedia wrote:
    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 c
                    an 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.

                      >> w
                      e 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.


    _______________________________________________
    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

GIF image


Back to the top