OPTION_MESSAGE_TIMEOUT client option depecation

[bennydiamond]

OPTION_MESSAGE_TIMEOUT client option depecation

[domasgim]

@bennydiamond we have encountered a similar situation in our solution using MQTT protocol as well, here's our solution to adjust queues message timeout, you can adjust these values according to your needs but with this patch the queued messages will be flushed after 10 seconds with one resend retry after 5 seconds:

This lowers timeout and retry values since we do not want
messages to be kept in internal SDK message queue for too long

There is OPTION_MESSAGE_TIMEOUT that may be used in the SDK
but it is deprecated

--- a/iothub_client/src/iothubtransport_mqtt_common.c
+++ b/iothub_client/src/iothubtransport_mqtt_common.c
@@ -46,8 +46,8 @@
 #define DEFAULT_CONNACK_TIMEOUT             30 // 30 seconds
 #define BUILD_CONFIG_USERNAME               24
 #define SAS_TOKEN_DEFAULT_LEN               10
-#define RESEND_TIMEOUT_VALUE_MIN            1*60
-#define TELEMETRY_MSG_TIMEOUT_MIN           2*60
+#define RESEND_TIMEOUT_VALUE_MIN            5
+#define TELEMETRY_MSG_TIMEOUT_MIN           10
 #define DEFAULT_CONNECTION_INTERVAL         30
 #define FAILED_CONN_BACKOFF_VALUE           5
 #define STATUS_CODE_FAILURE_VALUE           500

Or instead of a patch the two values right here https://github.com/Azure/azure-iot-sdk-c/blob/main/iothub_client/src/iothubtransport_mqtt_common.c#L50-L49

Do note that this may be considered a workaround for such problem but it suited our needs

[ericwol-msft]

connection and messaging reliability is documented here

We might have come into a situation where some devices have spotty communication with the cloud and outgoing messages (Device to cloud) are getting stuck and accumulated in doubly linked lists to the point the device runs out of memory

This SDK does not implement a max queue size as that is best determined by the application and platform requirements. You would need to implement an application dependent queue to be handle your application needs for messaging and monitor the sending of the messages and their corresponding status callbacks.

Normal operation of the SDK will temporarily hold on to the message and try to reconnect to the hub if disconnected due to infrastructure issue.

Connection Retry Policies can be set to application specific needs.

[ewertons]

Closing this issue based on the last comment from @ericwol-msft
Please feel free to reopen it or open a new one if you would like to follow up.
Thanks,
Azure IoT SDK Team