Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with MQTTAsync_disconnect: onDisconnectSuccess/onDisconnectFailure Not Triggered After onConnectionLost #1541

Open
SeaAndSand opened this issue Nov 26, 2024 · 2 comments

Comments

@SeaAndSand
Copy link

https://github.com/SeaAndSand/mqtt_test/blob/main/mqtt_client.c

Nov 24 01:15:47 [tcp://8.136.178.59:1883] [1c8776585442] 发送心跳, heartbeat_count = 9783
Nov 24 01:15:57 [tcp://8.136.178.59:1883] [1c8776585442] 发送心跳, heartbeat_count = 9783
Nov 24 01:16:07 [tcp://8.136.178.59:1883] [1c8776585442] 发送心跳, heartbeat_count = 9783
Nov 24 01:16:17 [tcp://8.136.178.59:1883] [1c8776585442] 发送心跳, heartbeat_count = 9783
Nov 24 01:16:27 [tcp://8.136.178.59:1883] [1c8776585442] 发送心跳, heartbeat_count = 9783
Nov 24 01:16:31 [tcp://8.136.178.59:1883] [1c8776585442] 收到回复,received_count = 9782
Nov 24 01:16:37 [tcp://8.136.178.59:1883] [1c8776585442] 发送心跳, heartbeat_count = 9783
Nov 24 01:16:47 [tcp://8.136.178.59:1883] [1c8776585442] Heartbeat timeout, disconnecting...
Nov 24 01:17:19 [tcp://8.136.178.59:1883] [1c8776585442] Failed to send message
Nov 24 01:17:19 [tcp://8.136.178.59:1883] [1c8776585442] Failed to send message
Nov 24 01:17:19 [tcp://8.136.178.59:1883] [1c8776585442] Failed to send message
Nov 24 01:17:19 [tcp://8.136.178.59:1883] [1c8776585442] Failed to send message
Nov 24 01:17:19 [tcp://8.136.178.59:1883] [1c8776585442] Connection lost: (null)

Actively calling MQTTAsync_disconnect, while waiting for onDisconnectSuccess or onDisconnectFailure, the onConnectionLost is triggered, and then the onDisconnectSuccess or onDisconnectFailure callback is never triggered. Why is this happening?

@icraggs
Copy link
Contributor

icraggs commented Nov 26, 2024

I can't say for sure but generally you would only get a connectionLost if you weren't connected. Your sending thread doesn't stop once the

You seem to have gone to a lot of effort to make this thread safe, when it's already thread safe, and to reproduce the included automatic reconnection mechanism? Unless there are other reasons?

More info, as requested in the template would help. Paho version, and a client library trace as described in the README.

@SeaAndSand
Copy link
Author

paho-mqtt-c version:1.3.13
myboard:arm32 linux 4.1.15

Adding a heartbeat is because I once encountered a situation where the network signal was actually disconnected. The MQTT server showed it was disconnected, and sending data also showed a failure, but connect_lost did not trigger immediately. Instead, it was delayed for 20 minutes before triggering.
Adding a reconnection mechanism is because if the first connection attempt fails, it will not trigger a reconnection.

The issue is occasional, and I did not have MQTT_C_CLIENT_TRACE enabled at the time, so I can only describe the phenomenon.

The phenomenon is that initially, the connection is established, and then we use a heartbeat to detect the connection status. If I detect multiple missed heartbeats, I will proactively disconnect and reconnect to prevent connect_lost from not triggering immediately. However, during the waiting period for the disconnection, connect_lost is triggered, and then the disconnection callback is not triggered.

In fact, I have now made a small modification. In connect_lost, if it detects that it is waiting for the disconnection callback, it will send a signal to wake it up. The disconnection also enabled the timeout parameter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants