Reconnect option

[ruicanas]

Hey guys! I'm currently using this library and I saw that, when the client fails it first connection, there is no chance of actually trying to reconnect automatically. My request would be: have a reconnect option that could be activated in the MQTT client's configuration. Would that be possible to do?

[adam-fowler]

Could you not just write

while true {
    do {
        try await client.connect()
        break
    } catch MQTTError.failedToConnect {
        try await Task.sleep(for: someExponentialIncreasingTimeAmount)
    }
}

[adam-fowler]

You need to call addPublishListener again. The first publish listener was waiting for events on the old client

[ruicanas]

Isn't it possible to keep the old client or make replacements directly on it? Since I'm reconnecting and only want to change an authentication parameter, adding a publish listener once again seems like I'm using a sledgehammer to crack a nut.

[adam-fowler]

@ruicanas would this work for you #143

[ruicanas]

@adam-fowler It would and it works like a charm. Thanks for adding this extra parameter. It makes everything much smoother and more straightforward.

[adam-fowler]

Released in v2.10.0

[leisurehound]

There are quite a few parameters to consider when doing a retry system.

• how long to wait between retries
• Should wait time increase exponentially/linearly after each fail and by how much
• Should wait time increase be jittered
• Should it fail after so many retries
• Should it fail after so much time
  I would rather the individual wrote their own, instead of the client providing an implementation that tries to support every combination of the above

Is there a better mechanism to use than client.isActive() to determine if the connection is still valid? I'm still seeing .isActive() true when the network interface/connection has been brought down, not really allowing me to use it to impl my own retry mechanism.

EDIT: looks like my interval for checking isAlive was shorter than the keepAlive interval. I was setting it near-ish the ping interval thinking a failed ping would result in it closing. But the CloseListener is called around when the keepAlive interval expires

[adam-fowler]

Although it looks like we might not be reacting to all forms of network connection closure. I'll need to review this

[leisurehound]

I'm seeing the close listener anywhere from 45s to 90s after I disconnect from wifi. However, in the console I see the nw_proto_tcp_route_init [C1.1.1:2] no mtu received message immediately. would be great if we can see the call to the close listener and isActive() reflect the state sooner.

[adam-fowler]

Hi @leisurehound could you add an issue for this including all your platform details. 🙏

[leisurehound]

done

Separately, when the close listener is finally called, are all the client's eventloops terminated? On both linux and macOS?

[adam-fowler]

The eventLoopGroup is only shutdown when you call MQTTClient.shutdown. If you provide your own EventLoopGroup then it is never shutdown as it is assumed you are using it for other processes