| 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. 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:
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:
On Fri, Aug 15, 2014 at 4:19 AM, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
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:
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:
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 -------------------------------------------------------------------------------------------
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:
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:
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:
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:
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:
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:
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 |
