DisconnectSuccess/DisconnectFailure Not Triggered After ConnectionLost

[SeaAndSand]

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]

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]

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.

[icraggs]

Well the keep alive is intended to do exactly as you need so it's a lot of extra work for you.

Anyway what I suspect is happening is that the connection lost being recognized is overlapping your call to disconnect. This is probably quite a hard situation to achieve normally, as I was trying to envisage a (simple) test for it.

As you are doing your own keep alive with the same time interval as the MQTT keep alive, it would seem prudent to switch off the MQTT one (set keep alive interval to 0). They are doing exactly the same thing and could get in each other's way. Whether they are in this case, I'm not sure yet.