• State Verified Answer
  • Replies 2 replies
  • Subscribers 89 subscribers
  • Views 587 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 280418
Options

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

aldras

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

Parents
  • +1

    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

Reply
  • +1

    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

Children
  • 0 in reply to Amanda Hsieh

    Hi Amanda,

    Thank you for the quick reply and confirmations.  I am beginning to investigate the reason for the ENOMEM error on reconnect now.  It may or may not be related to socket handling, but seeing a previous thread (although over a year old) thought I would ask for conformation.

    I need a little time to setup the test environment and other things on this end and will report in this thread what happens, however, it can take days for the disconnection (and reconnection attempt) to occur.

    Currently I have a Raspberry Pi (very low power consumption compared to running a full PC) setup to log the UART debug output, but if it is modem traces I might have to rethink this setup.

    Sincerely,
    Allan

Related