nRF9160 Azure azure_iot_hub reconnect attempt after disconnect returning error -12 ENOMEM

Question

I am currently working with SDK 1.7.1, using the azure_iot_hub sample application. 
 This is a continuation of this topic: 
 https://devzone.nordicsemi.com/f/nordic-q-a/82164/nrf9160-azure-azure_iot_hub-reconnect-failed-not-notifying-application 
 
 Further to clarify an issue I have run into, I have found something related in another topic here: 
 https://devzone.nordicsemi.com/f/nordic-q-a/56240/mqtt-socket-error-after-4-consecutive-mqtt-connect-disconnect 
 To quote from this above topic... 
 "You need to call mqtt_live() after mqtt_disconnect() for the mqtt library to close the socket. 
 If not, you will run out of sockets, and get ENOMEM (-12)." 
 
 Although the issue I believe I was having is that I was not handling a connect error correctly when attempting to reconnect to Azure (MQTT) however, I believe that I will encounter this error ENOMEM even if I implement the functionality to reattempt the reconnection upon receiving this error -12 (ENOMEM). 
 In the mean time I will attempt to implement the reconnection retry code, however, I believe I may encounter this above error on every reconnect attempt. 
 Can I verify that upon disconnect from Azure due to network issues or Azure server issues (aka receiving the event AZURE_IOT_HUB_EVT_DISCONNECTED) that the socket(s) will be cleared to avoid running out of sockets? As last recourse I can perform a soft reset to recover and reconnect upon Azure disconnection, but would like to avoid this if possible. 
 If this is not the case, can I clear the sockets in the application layer using mqtt_live()? I would prefer to not bypass and directly access objects that are managed in the library if possible. 
 Sincerely, Allan

Amanda Hsieh · Accepted Answer

Hi, 
 From the team: 
 "You need to call mqtt_live() after mqtt_disconnect() for the mqtt library to close the socket. 
 If not, you will run out of sockets, and get ENOMEM (-12)." 
 This should not be the case anymore. 
 
 Although the issue I believe I was having is that I was not handling a connect error correctly when attempting to reconnect to Azure (MQTT) however, I believe that I will encounter this error ENOMEM even if I implement the functionality to reattempt the reconnection upon receiving this error -12 (ENOMEM). 
 In the mean time I will attempt to implement the reconnection retry code, however, I believe I may encounter this above error on every reconnect attempt. 
 The calls to azure_iot_hub_connect() should not cause memory leaks, as this is handled by the underlying MQTT libraries in Zephyr. 
 But if you are indeed running out of sockets, we would like to investigate this further. If possible, it would be of great help to receive the following: 
 
 Full application logs, preferably with debug logs enabled 
 Application code, or a minimal sample reproducing the issue 
 Modem traces 
 
 I can make this case private to share those with Nordic if you want. 
 Can I verify that upon disconnect from Azure due to network issues or Azure server issues (aka receiving the event AZURE_IOT_HUB_EVT_DISCONNECTED) that the socket(s) will be cleared to avoid running out of sockets? As last recourse I can perform a soft reset to recover and reconnect upon Azure disconnection, but would like to avoid this if possible. 
 When AZURE_IOT_HUB_EVT_DISCONNECTED is received, the socket should already have been closed. I have not been able to reproduce out-of-sockets situations after repeated calls to connect() and _ disconnect() calls, but will continue to investigate. 
 
 If this is not the case, can I clear the sockets in the application layer using mqtt_live()? I would prefer to not bypass and directly access objects that are managed in the library if possible. 
 The socket should indeed be handled fully by the library, so it should not be necessary to close it from the application side. 
 
 Regards, Amanda

nRF9160 Azure azure_iot_hub reconnect attempt after disconnect returning error -12 ENOMEM

Top Replies