Вопрос в том, что вы делаете даже в том случае, если сообщение об ошибке возникает в случае, если очередь заполнена? Вы теряете информацию из-за нехватки памяти? С точки зрения IoT, я бы рекомендовал в этом случае рассмотреть вопрос о том, является ли ваше устройство надежным устройством IoT для обработки этих крайних случаев. А также знание границ устройств и знание того, как долго это может продолжаться без подключения к интернету, помогает снизить эти риски для вашего приложения, а не SDK.
Из GitHub метод sendMessageAsync по умолчанию генерирует исключение тайм-аута в случае сбоя при отправке сообщения, если у вас не реализованы какие-либо политики повторных попыток (согласно документации C SDK не допускает настраиваемые политики повторных попыток).
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-reliability-features-in-sdks).
В соответствии с документацией в случае сбоя соединения на основе политики повторных попыток (если вы ее установили) SDK попытается так или иначе инициировать соединение и поставить в очередь сообщения, созданные за это время:
https://github.com/Azure/azure-iot-sdk-c/blob/master/doc/connection_and_messaging_reliability.md
Итак, здесь ожидается, что SDK не несет ответственности за пределы памяти. Это до приложения, чтобы иметь дело. Поскольку ваше устройство имеет некоторые ограничения, я бы порекомендовал реализовать собственный механизм организации очередей (возможно, в качестве политики установите no-retry и таким образом избегайте очередей). Таким образом, вы контролируете, что произойдет в случае отсутствия подключения к Интернету и ограничения памяти. Может быть, ваше экономическое обоснование допускает, что вы вычисляете среднее значение, и вместо 50 вы сохраняете одно сообщение в течение определенного времени и т. Д.
Если это то, что вам не нравится, в документации также сказано, что вы установили тайм-аут для очереди - может быть, не предел памяти, а тайм-аут да, поэтому, возможно, вы можете попытаться исследовать это немного глубже:
"В этой системе есть два элемента управления тайм-аутом. Оригинальный в слое iothub_client_ll, который контролирует очередь" ожидающих отправки ", и современный в транспортном уровне протокола, который применяется к списку" в процессе " Однако, поскольку IoTHubClient_LL_DoWork вызывает немедленную * обработку, отправку и перемещение телеметрических сообщений в список «в процессе», первый тайм-аут управления практически не применяется.
Оба могут быть точно настроены пользователями через IoTHubClient_LL_SetOption, и из-за этого удаление исходного элемента управления может вызвать перерыв для существующих клиентов. По этой причине он был сохранен как есть, но он будет изменен, когда мы перейдем к следующей основной версии продукта. "