migrated from Bugzilla #482634
status UNCONFIRMED severity normal in component MQTT-Android for 1.2
Reported in version v0.5 on platform Other
Assigned to: James Sutton
Original attachment names and IDs:
On 2015-11-19 19:02:34 -0500, Luxi Liu wrote:
Hi There,
I'm using 'org.eclipse.paho:org.eclipse.paho.client.mqttv3:1.0.3-SNAPSHOT' and 'org.eclipse.paho:org.eclipse.paho.android.service:1.0.3-SNAPSHOT' to develop an Android app, which subscribes topics for messages from our own MQTT server.
As the MQTT server is not pingable, if there's no message coming, after the keep-alive-interval, the connection will be lost. On user's appropriate operation, the app will re-connect to the server if MqttAndroidClient.isConnected() returns false.
Then problem is:
The callback onSuccess() of MqttAndroidClient.connect() for this reconnection attempt, will be called twice. And the callback messageArrived() for the subscribed message coming through, will be called twice as well.
If the app re-connects for the 3rd time, the callbacks will be called 3 times; 4th, 4 times; 5th, 5 times; ...
I tried MqttAndroidClient.setKeepAliveInterval(), but it seems this API doesn't work at all, because no matter what value I set, the connection is always lost after 60 secs.
Initially, I used the libraries of 1.0.2 in release repo and I met this problem. Still no luck after changing to 1.0.3 in snapshot repo.
I found a similar bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=462619, which was already fixed. I'm not sure whether they're related or not.
Thank you!
On 2015-11-19 19:20:41 -0500, Luxi Liu wrote:
Confirm that SNAPSHOT has fixed this issue. But setKeepAliveInterval() still doesn't work in this case.
Thanks.
On 2015-11-25 06:37:53 -0500, James Sutton wrote:
Hi Luxi,
The Keep Alive value is only sent when the client connects to the server. Once that has happened, that value will be used for the remainder of the connection and cannot be changed.
It sounds like you're trying to change the keep alive after you have connected which would not have any effect on the connection. But MqttAndroidClient doesn't have a setKeepAliveInterval so I'm guessing that you're actually talking about MqttConnectOptions right?
On 2015-11-25 18:21:59 -0500, Luxi Liu wrote:
(In reply to James Sutton from comment # 2)
Hi Luxi,
The Keep Alive value is only sent when the client connects to the server.
Once that has happened, that value will be used for the remainder of the
connection and cannot be changed.
It sounds like you're trying to change the keep alive after you have
connected which would not have any effect on the connection. But
MqttAndroidClient doesn't have a setKeepAliveInterval so I'm guessing that
you're actually talking about MqttConnectOptions right?
Yes, it's MqttConnectOptions. The code is as below,
MqttConnectOptions mqttConnectOptions = new MqttConnectOptions();
mqttConnectOptions.setUserName(getUsername());
mqttConnectOptions.setPassword(getAccessToken().toCharArray());
mqttConnectOptions.setKeepAliveInterval(60 * 5);
mMqttAndroidClient.connect(mqttConnectOptions(), null, this);
No matter what value I give to setKeepAliveInterval(), the connected connection always connectionLost() after 60 sec, which is default value.
On 2015-11-27 08:34:04 -0500, James Sutton wrote:
I've not been able to recreate this on my nexus 5 with the sample app. What type of MQTT broker are you using? I've tested with the Mosquitto Broker on iot.eclipse.org which seems to work well.
On 2015-11-27 17:43:33 -0500, Luxi Liu wrote:
(In reply to James Sutton from comment # 4)
I've not been able to recreate this on my nexus 5 with the sample app. What
type of MQTT broker are you using? I've tested with the Mosquitto Broker on
iot.eclipse.org which seems to work well.
Try with an unpingable broker
On 2015-11-30 04:50:17 -0500, James Sutton wrote:
(In reply to Luxi Liu from comment # 5)
(In reply to James Sutton from comment # 4)
I've not been able to recreate this on my nexus 5 with the sample app. What
type of MQTT broker are you using? I've tested with the Mosquitto Broker on
iot.eclipse.org which seems to work well.
Try with an unpingable broker
If a broker does not respond to a PINGREQ then it is not compliant with the MQTTv3.1.1 spec and so would not be supported. http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718081
What broker does not respond to PINGREQs and why would you want to use it over other types?
On 2015-11-30 19:19:42 -0500, Luxi Liu wrote:
(In reply to James Sutton from comment # 6)
(In reply to Luxi Liu from comment # 5)
(In reply to James Sutton from comment # 4)
I've not been able to recreate this on my nexus 5 with the sample app. What
type of MQTT broker are you using? I've tested with the Mosquitto Broker on
iot.eclipse.org which seems to work well.
Try with an unpingable broker
If a broker does not respond to a PINGREQ then it is not compliant with the
MQTTv3.1.1 spec and so would not be supported.
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.
html#_Toc398718081
What broker does not respond to PINGREQs and why would you want to use it
over other types?
It's an internally used server.
So for an unable-to-ping server, setKeepAliveInterval() cannot work?
The actual problem becomes:
- Connected to this unable-to-ping server with setKeepAliveInterval(300), 2. There's no message coming through within 300 secs, and at the same time, the ping message is not responded.
- After 60 secs, which is the default, the connection is lost.
On 2015-12-01 04:07:00 -0500, James Sutton wrote:
Right, I was thrown because in your example you were setting a keep alive value. If any keepalive interval is set, the client will also disconnect because the server is not responding. Set the keepalive interval to 0 which will disable keepalive processing in the client.
On 2015-12-01 08:21:27 -0500, Luxi Liu wrote:
(In reply to James Sutton from comment # 8)
Right, I was thrown because in your example you were setting a keep alive
value. If any keepalive interval is set, the client will also disconnect
because the server is not responding. Set the keepalive interval to 0 which
will disable keepalive processing in the client.
Unfortunately, setKeepAliveInterval(0) doesn't work, after 60 sec, the connection is still lost.
On 2015-12-01 08:44:12 -0500, Luxi Liu wrote:
The connection is SSL via port 8883.
On 2015-12-01 08:51:36 -0500, James Sutton wrote:
Created attachment 258391
Log file showing connection with keepalive of 0
On 2015-12-01 08:55:03 -0500, James Sutton wrote:
Comment on attachment 258391
Log file showing connection with keepalive of 0
12-01 13:43:22.667 24706-25857/org.eclipse.paho.android.sample D/AlarmPingSender: Register alarmreceiver to MqttServiceMqttService.pingSender.AndroidExampleClient
12-01 13:43:22.669 24706-25857/org.eclipse.paho.android.sample D/AlarmPingSender: Schedule next alarm at 1448977402669
12-01 13:43:22.674 24706-24706/org.eclipse.paho.android.sample I/ActionListener: L73AFSOP-iot.eclipse.org-AndroidExampleClient connected.
12-01 13:43:22.674 24706-24706/org.eclipse.paho.android.sample I/ActionListener: Auto-subscribing to: /jsutton23/test@ QoS: 0
12-01 13:43:27.672 24706-24706/org.eclipse.paho.android.sample D/AlarmPingSender: Ping 1 times.
12-01 13:43:27.672 24706-24706/org.eclipse.paho.android.sample D/AlarmPingSender: Check time :1448977407672
12-01 13:43:55.006 24706-24706/org.eclipse.paho.android.sample I/System.out: GOT A MESSAGE in history Incoming Message Test
12-01 13:43:55.006 24706-24706/org.eclipse.paho.android.sample I/System.out: M: 1
12-01 13:43:55.014 24706-24706/org.eclipse.paho.android.sample I/MqttCallbackHandler: Received message Incoming Message Test
Topic: /jsutton23/test;qos:0;retained:false
12-01 13:48:13.437 24706-24706/org.eclipse.paho.android.sample I/System.out: GOT A MESSAGE in history Incoming Message Test
12-01 13:48:13.438 24706-24706/org.eclipse.paho.android.sample I/System.out: M: 2
12-01 13:48:13.439 24706-24706/org.eclipse.paho.android.sample I/MqttCallbackHandler: Received message Incoming Message Test
Topic: /jsutton23/test;qos:0;retained:false
12-01 13:48:23.616 24706-30786/org.eclipse.paho.android.sample D/AlarmPingSender: Unregister alarmreceiver to MqttServiceAndroidExampleClient
On 2015-12-01 08:56:14 -0500, Luxi Liu wrote:
(In reply to James Sutton from comment # 12)
Comment on attachment 258391 [details]
Log file showing connection with keepalive of 0
12-01 13:43:22.667 24706-25857/org.eclipse.paho.android.sample
D/AlarmPingSender: Register alarmreceiver to
MqttServiceMqttService.pingSender.AndroidExampleClient
12-01 13:43:22.669 24706-25857/org.eclipse.paho.android.sample
D/AlarmPingSender: Schedule next alarm at 1448977402669
12-01 13:43:22.674 24706-24706/org.eclipse.paho.android.sample
I/ActionListener: L73AFSOP-iot.eclipse.org-AndroidExampleClient connected.
12-01 13:43:22.674 24706-24706/org.eclipse.paho.android.sample
I/ActionListener: Auto-subscribing to: /jsutton23/test@ QoS: 0
12-01 13:43:27.672 24706-24706/org.eclipse.paho.android.sample
D/AlarmPingSender: Ping 1 times.
12-01 13:43:27.672 24706-24706/org.eclipse.paho.android.sample
D/AlarmPingSender: Check time :1448977407672
12-01 13:43:55.006 24706-24706/org.eclipse.paho.android.sample I/System.out:
GOT A MESSAGE in history Incoming Message Test
12-01 13:43:55.006 24706-24706/org.eclipse.paho.android.sample I/System.out:
M: 1
12-01 13:43:55.014 24706-24706/org.eclipse.paho.android.sample
I/MqttCallbackHandler: Received message Incoming Message Test
Topic: /jsutton23/test;qos:0;retained:false
12-01 13:48:13.437 24706-24706/org.eclipse.paho.android.sample I/System.out:
GOT A MESSAGE in history Incoming Message Test
12-01 13:48:13.438 24706-24706/org.eclipse.paho.android.sample I/System.out:
M: 2
12-01 13:48:13.439 24706-24706/org.eclipse.paho.android.sample
I/MqttCallbackHandler: Received message Incoming Message Test
Topic: /jsutton23/test;qos:0;retained:false
12-01 13:48:23.616 24706-30786/org.eclipse.paho.android.sample
D/AlarmPingSender: Unregister alarmreceiver to
MqttServiceAndroidExampleClient
In you log, you have got messages coming. Have you try if no message coming and going at all?
On 2015-12-01 08:57:19 -0500, Luxi Liu wrote:
- setkeepalive(0)
- makre sure no message received or sent.
after 60 secs, the connection will be lost
On 2015-12-01 09:03:58 -0500, James Sutton wrote:
So I gave it a try where I used the Sample App to connect to the mosquitto broker at iot.eclipse.org with a keepalive of 0.
As you can see in the attached log, the client connected to the broker at 13:43, auto subscribed to a topic and began a ping which immediately stopped because keepalive was set to 0. Note: It did not re-schedule. I then sent a test message, then waited about 5 minutes before sending another to make sure that the client was still connected and then disconnected.
If the connection is dropping for you, then it could be a genuine connectivity issue or an issue with your broker.
Do you have any logs to support that the keepalive value is not being honoured?
On 2015-12-02 01:22:18 -0500, Luxi Liu wrote:
(In reply to James Sutton from comment # 15)
So I gave it a try where I used the Sample App to connect to the mosquitto
broker at iot.eclipse.org with a keepalive of 0.
As you can see in the attached log, the client connected to the broker at
13:43, auto subscribed to a topic and began a ping which immediately stopped
because keepalive was set to 0. Note: It did not re-schedule. I then sent a
test message, then waited about 5 minutes before sending another to make
sure that the client was still connected and then disconnected.
If the connection is dropping for you, then it could be a genuine
connectivity issue or an issue with your broker.
Do you have any logs to support that the keepalive value is not being
honoured?
I can only see
D/AlarmPingSender: Unregister alarmreceiver to MqttServiceau.com.netcabs.oiii.352136069698666
D/ContentManager: MqttAndroidClient: connectionLost(In reply to James Sutton from comment # 15)
So I gave it a try where I used the Sample App to connect to the mosquitto
broker at iot.eclipse.org with a keepalive of 0.
As you can see in the attached log, the client connected to the broker at
13:43, auto subscribed to a topic and began a ping which immediately stopped
because keepalive was set to 0. Note: It did not re-schedule. I then sent a
test message, then waited about 5 minutes before sending another to make
sure that the client was still connected and then disconnected.
If the connection is dropping for you, then it could be a genuine
connectivity issue or an issue with your broker.
Do you have any logs to support that the keepalive value is not being
honoured?
I only have the following log
D/AlarmPingSender: Unregister alarmreceiver to MqttServiceau.com.abc.def.352136069698666
D/ContentManager: MqttAndroidClient: connectionLost
After 60 sec, the connect is lost. How can I get more detail log?
On 2015-12-02 05:33:12 -0500, James Sutton wrote:
Unfortunately for connectionLost there aren't really any more logs that could be shown. In your connectionLost callback, you could take the exception and print it to your console.
@OverRide
public void connectionLost(Throwable cause) {
if (cause != null) {
System.out.println("Connection Lost: " + cause.getMessage());
}
}
As you are also using a custom broker, you could try adding your own logging to that to look at the life cycle of the client. It may explain why your client is loosing the connection.
I recommend that you also test with iot.eclipse.org or a mosquitto broker to see if the client behaves the same way. If the client does not lose connection after 60 seconds then it is likely that the issue lies with either the route between the client and broker or the broker itself.
On 2015-12-17 09:55:35 -0500, James Sutton wrote:
Hi, Any Luck with this?
On 2015-12-21 22:11:42 -0500, Luxi Liu wrote:
(In reply to James Sutton from comment # 18)
Hi, Any Luck with this?
Hi,
I believe something's different with our own MQTT server, because the issue is not found with any other brokers
On 2015-12-22 06:36:31 -0500, Ian Craggs wrote:
Hi, James is on vacation now until January.
What would really help is to find out why the server is disconnecting the client. Depending on the MQTT server, there should be a log message or other explanation available. If this doesn't happen with any other MQTT server, maybe the server has a problem, or a mismatch in expectations between the client and server?
On 2015-12-22 16:14:56 -0500, Luxi Liu wrote:
(In reply to Ian Craggs from comment # 20)
Hi, James is on vacation now until January.
What would really help is to find out why the server is disconnecting the
client. Depending on the MQTT server, there should be a log message or
other explanation available. If this doesn't happen with any other MQTT
server, maybe the server has a problem, or a mismatch in expectations
between the client and server?
But I tried a ruby testing script, to connect first, sleep for more than 60 secs, then publish and receive message. The script can work, no auto disconnected issue