Is there already some feedback from SSP developers? I am especially interested if the workaround I describe is a possible solution...
No, there has been no response for the SSP developers. However, form looikng at the SSP MQTT source code, I would it is a valid workaround until it is fixed in the Expresslogic MQTT client code.
On the inital connect nxd_mqtt_ping_not_responded will be zero.
part of the process of connecting involves creating a threadx timer (_nxd_mqtt_periodic_timer_entry) to periodically check if the ping response has been received :-
When reconnecting after a disconnect because a ping was not received, nxd_mqtt_ping_not_responded will be true and the timer _nxd_mqtt_periodic_timer_entry will potentially signal a disconnect. Setting _nxd_mqtt_periodic_timer_entry to NX_FALSE (0) before the recoonection, means the periodic timer will not signal a disconnect until a ping is not received for that particular connection (rather than the failed ping that caused the previous disconnect).
The offical fix might also do some more cleaning up than just setting _nxd_mqtt_periodic_timer_entry to NX_FALSE (0)
Hi Jeremy
Thanks for your feedback, this helped me a lot. So my fix is working and I can go ahead with it until the problem is fixed within SSP.
But something is confusing me. You write that "_nxd_mqtt_periodic_timer_entry" should be set to NX_FALSE before reconnecting. But this is the timer callback function as I understand? Did I miss something? Or did you mix up the names?
Regards, Pi