MQTT Con thread leak on connection failure

[MMaiero]

Please fill out the form below before submitting, thank you!

• [x] Bug exists Release Version 1.2.5 ( Master Branch)
• [ ] Bug exists in MQTTv3 Client on Snapshot Version 1.2.6-SNAPSHOT (Develop Branch)
• [ ] Bug exists in MQTTv5 Client on Snapshot Version 1.2.6-SNAPSHOT (Develop Branch)

If this is a bug regarding the Android Service, please raise the bug here instead: https://github.com/eclipse/paho.mqtt.android/issues/new

Hello, we are currently using Paho 1.2.1 but we have verified that the same issue seems to be still there with later versions of the bundle. It happens that when the broker accepts a connection and then drops it immediately, the MQTT con thread remains stuck here: https://github.com/eclipse/paho.mqtt.java/blob/6f35dcb785597a6fd49091efe2dba47513939420/org.eclipse.paho.client.mqttv3/src/main/java/org/eclipse/paho/client/mqttv3/internal/CommsReceiver.java#L83

It seems that the following sequence of events can lead to the problem:

1. Paho connects and starts the receiver thread, calling: https://github.com/eclipse/paho.mqtt.java/blob/5af7b53499e7dbe45b7227b3d41fc870089c0033/org.eclipse.paho.client.mqttv3/src/main/java-templates/org/eclipse/paho/client/mqttv3/internal/ClientComms.java#L724
2. The Con thread sleeps waiting for the receiver thread to start: https://github.com/eclipse/paho.mqtt.java/blob/v1.2.5/org.eclipse.paho.client.mqttv3/src/main/java/org/eclipse/paho/client/mqttv3/internal/CommsReceiver.java#L84
3. The receive thread starts reading but gets an IOException because the broker already closed the connection: https://github.com/eclipse/paho.mqtt.java/blob/v1.2.5/org.eclipse.paho.client.mqttv3/src/main/java/org/eclipse/paho/client/mqttv3/internal/CommsReceiver.java#L137 that leads to https://github.com/eclipse/paho.mqtt.java/blob/570ed6eeaba81b0865821fed6de0d36142fedfde/org.eclipse.paho.client.mqttv3/src/main/java/org/eclipse/paho/client/mqttv3/internal/CommsReceiver.java#L197 The ending state of the read thread will be STOPPED
4. Since the read thread state is stopped and the MQTT con thread was not able to see the transition to the starting or running state, the thread never exits the loop and is leaked.

Every disconnect tentative even if forcibly will not lead to solve the issue.

[royi-klein]

Hi - I have this issue reproduced in production generating thousands of threads (MQTT Con threads). any way to overcome this? can't the connection threads (Rec, Snd, Call) be created in a blocking manner? Thanks!