`stop`s when connect fails

[ryanwinchester]

When connection fails you stop_and_reply

https://github.com/emqx/emqtt/blob/master/src/emqtt.erl#L617-L630

but I would not like this to happen. Depending on the reason, I'd like to just try reconnecting with my own custom logic (like exponential backoff with jitter) but this makes it much more difficult to do. Wouldn't it be better to let the user of the library decide when they want to stop?

[ryanwinchester]

Not sure if this is related to #84

[tigercl]

@ryanwinchester Thank you for using emqtt. In general, if the connection fails for the first time, it means that the server has not been started or there are other problems, so we think it is reasonable to give the reconnection logic to the user.

[ryanwinchester]

Thanks, I'll try to add more detail why it's harder to use this way:

Stopping emqtt also stops my gen_server that is using it. So, now I have to:

1. have a gen_server that wraps emqtt that implements start instead of start_link
2. monitor the first gen_server for DOWN
3. demonitor and restart it and rebuild the state, and start monitoring that one
4. repeat if server is not up yet

Instead of just retrying emqtt:connect from my original gen_server (probably with some backoff logic, or however I want), which would be much easier for me to retry connecting if it fails, but I can't because you've stopped it.

Am I explaining my problem well enough? I'm not good at explaining sometimes.

[pallix]

This issue is serious and my team will probably switch back to Elixir Tortoise because of it, even if the performance of emqtt were better.

so we think it is reasonable to give the reconnection logic to the user.

When connect fails, the emqtt process exit, making this reconnection logic way more difficult to implement as necessary: it's not possible to just call connect again after a delay for example. To call connect again, the process need first to be restarted. Where things become complicate is that the emqtt process parent (a supervisor for example) and the process calling connect are most of the time two different processes, making this reconnect logic cumbersome to implement.

Returning {:error, :econnrefused} without exiting would be enough to ensure safety and simplify the whole thing.

[philipcristiano]

I'm running into this as well. It's a bit of a headache to deal with the child terminating instead of getting a response from the connect call.

[RKushnir]

Is there an intention to address this issue? It causes the whole app to exit immediately if the broker is not available during the startup. Alternatively, we have to turn to a hacky workaround. This is a big downside for an otherwise great library.

[emiltin]

I'm also curious - any plans to address this?

[emiltin]

I really hope this can be adressed.