Resubscribe automatically if automatically reconnecting but session expired

[SgtSilvio]

identified with #293

somewhat related to #288

[SgtSilvio]

@adamcrane please vote on this if you are interested to turn this into a feature request.

[adamcrane]

Yes we would like to turn this into a feature request

[lemoony]

Hi @SgtSilvio , is this ticket about implementing an automatic resubscribe mechanism? The thing about "session expired" confused me a bit.

I think it is a bit weird for the client to only support resubscribptions in combination with the Reactive Api and the retry() operator.

Why would anyone using the reconnect mechanism not also want to resubscribe to previous topics? Would be great if this was made into a feature request.

BTW: Still and nonetheless - best mqtt client library for java out there 👍

[SgtSilvio]

Currently automatic reconnect only makes sense if you have a session with a sufficient session expiry. As long as the MQTT broker has a session you do not need to resubscribe as the subscriptions are still valid. Generally it is recommended to have a persistent session when having a use case for automatic reconnect.

I understand that users expect that automatic reconnect restores the subscriptions in case the session expired, so I added the feature label.

I did not remove the question label yet as it is not sure how the subscriptions should be restored.
Consider the following subscriptions

• subscribe call 1: "a", "b"
• subscribe call 2: "c"
• subscribe call 3: "a"

Should the resubscription also send 3 separate subscribes (most likely in a different order) or a combined subscribe with all topic filters ("a", "b", "c", "a")?

[SgtSilvio]

I did not remove the question label yet as it is not sure how the subscriptions should be restored.
Consider the following subscriptions

• subscribe call 1: "a", "b"
• subscribe call 2: "c"
• subscribe call 3: "a"

Should the resubscription also send 3 separate subscribes (most likely in a different order) or a combined subscribe with all topic filters ("a", "b", "c", "a")?

The current implementation restores the subscriptions grouped as in its original Subscribe packets. For each duplicate subscription to the same topic filter only the last successful subscription is restored.
The subscriptions are restored with the same subscription options (max QoS, no local, retain handling, retain as published) as the last successful subscription for its topic filter.
The Subscribe packets are also restored with the same subscription identifier, but user properties are currently not (re)stored.

In the above example this would be:

• restored subscribe packet 1: "b"
• restored subscribe packet 2: "c"
• restored subscribe packet 3: "a"

[SgtSilvio]

@adamcrane @lemoony automatic resubscribe was finally released with version 1.2.0