TTL for Max Inflight Message queue in V1 SDK and V2 SDK

[mogambo100]

Team,
For the V1 SDK we have a max inflight message queue which contains messages which are unacknowledged and retain them in the queue. The default value of queue is 10. Currently we are using the V1 SDK with AWsIotMqttClient which recently encounetered this issue due to an outage in IoT core. But as outage recovered on Iot end our queue didn't recovered and service was still down. We need to manually delete and recreate the queue.
Q1. Is there any way to set TTL for the messages which are in queue so that after that TTL they are automatically dropped form the queue.
Q2. Now we are migrating to V2 sdk. If the same max inflight unacknowledged message queue is being used then is there any way for TTL in V2 sdk. If its being not used or this condition will never come then the possible reason for the same.

[TwistedTwigleg]

Hi @mogambo100,

You can set a timeout for operations in the Java V1 and V2 SDKs to avoid the issue where the server is down and therefore operations just sit in the queue.

---

For Java V1, you can do something like the following on a per operation basis:

long timeout = 3000;  // milliseconds
client.publish(message, timeout);

All operations can have a timeout associated with them, as described in the Java V1 Readme. This will prevent the operations from just sitting in the queue endless waiting.

---

For Java V2, a timeout can be applied on a per-operation basis using the following:

CompletableFuture<Integer> published = connection.publish(new MqttMessage(topic, message.getBytes(), QualityOfService.AT_LEAST_ONCE, false));
published.get(60, TimeUnit.SECONDS);

You can also set an operation timeout for all operations in the MqttConnection through the withProtocolOperationTimeoutMs function:

AwsIotMqttConnectionBuilder builder = AwsIotMqttConnectionBuilder.newMtlsBuilderFromPath(
                getCommandRequired(m_cmd_cert_file, ""), getCommandRequired(m_cmd_key_file, ""));
builder.withProtocolOperationTimeoutMs(3000);

Either way will add a timeout and prevent operations from just sitting endlessly waiting.

[mogambo100]

Thanks @TwistedTwigleg . For V1 SDK i got the point. For V2 SDK i wanted to know one thing,
I am currently migrating the existing service from v1 to v2 and I had set timeouts on CompletableFutures. Is it necessary to have withProtocolOperationTimeoutMs also added as a property in MqttClientConfig

Q2. Lets say we add both the things and both set at same value of 5000ms. Will that create an issue
Q3. If both do the same workaround then Its better to have protocolOperationTimeout rather than future based?

[TwistedTwigleg]

I am currently migrating the existing service from v1 to v2 and I had set timeouts on CompletableFutures. Is it necessary to have withProtocolOperationTimeoutMs also added as a property in MqttClientConfig

No, it is not necessary to have withProtocolOperationTimeoutMs set for timeouts if you are timing out the futures in Java using .get(<duration>, TimeUnit.<unit>). When you call published.get(60, TimeUnit.SECONDS); in Java, for example, that will timeout the operation in 60 seconds if it does not complete in time regardless of the withProtocolOperationTimeoutMs setting set.

If your operations were not timing out but you had timeouts set on the futures in Java, then I am not sure why they did not timeout correctly. If you have functionality that is waiting on a publish to be received or similar, then perhaps that could be what caused the issue rather than the timeout itself. Without more information and looking at the logs when the event occurred, it is hard to say what could have caused the issue.

Q2. Lets say we add both the things and both set at same value of 5000ms. Will that create an issue

I would not expect it to cause an issue. Once an operation has been marked as a "fail" due to a timeout or for a different reason, it should be completed and another timeout shouldn't change that nor cause issues.

Q3. If both do the same workaround then Its better to have protocolOperationTimeout rather than future based?

It depends on your use case and how much control you want over the wait time for individual operations. If you want ALL operations to always have the same timeout, then using protocolOperationTimeout and not using any futures should be fine. On the other hand, if you have operations you want to timeout at different rates (like you want connections not to timeout as quickly as publishes, for example) then you could set the protocolOperationTimeout to the longest possible operation timeout you wish to support and then use the future timeout in Java for operations you want to timeout in a shorter period.

Something else to consider is that protocolOperationTimeout sets the timeout for all operations, and this may or may not be desired. If you want to only selectively timeout certain operations, then you would not want to use protocolOperationTimeout and instead exclusively use the future timeouts in Java instead to avoid adding timeouts to operations you do not with to timeout.

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.