Hi @Grégoire DEFOY, Thanks for sharing more information. Sending one telemetry message, two packets will be used, nx_azure_iot_hub_client_telemetry_message_create
allocates the packet (first packet), then MQTT client (QoS1) copies one packet (second packet), the second packet will not be released until MQTT PUB ACK response is received. The first packet will be added TCP header, IP header and sent out in driver (call nx__packet__transmit_release() to mark the packet has been transmitted*.*), then the first packet will not be released until TCP ACK is received. In your scenario, the issue is to send telemetry message too fast with limited packets, it is not a thread priority problem. As you tested, you may increase the packet count, add the check for available packets before allocating a telemetry message, or slow down telemetry transmission.
Packet pool is depleted when too much messages are sent via the azure RTOS C Iot sdk
Grégoire DEFOY
20
Reputation points
When rapid firing telemetry messages with nx_azure_iot_hub_client_telemetry_message_create
and
nx_azure_iot_publish_mqtt_packet
, I noticed that when the memory allocation fails, the packet pool that the IoT client is using is depleted and no packets are released, is this expected behaviour ? what can I do to prevent this and get back the memory ? Is this due to Qos 1 that will not release packets until they are sent ?
This issue happens whether I send packets with my cellular or wi-fi interface so I don't think this is an issue caused by underlying drivers
Accepted answer
-
Bo Chen 596 Reputation points Microsoft Employee
2023-05-04T02:33:55.2533333+00:00