MqttClient seems not to re-connect automatically about vertx-mqtt

[Sammers21]

Hi @ctron , actually automatic reconnection is not supported yet. But, you can implement it with MqttClient#closeHandler(just call connect on closeHandler triggering). The field in MqttClientOptions is useless, please, ignore it.

If you'd like to fix it - feel free to contribute.

[ctron]

Well it can't be implemented 100% with the close handler as it looks to me.

When the connection succeeds, then the close handler will be called. However when the initial connection doesn't succeed, only the Future is completed with a failure:

if (done.failed()) {
  log.error(String.format("Can't connect to %s:%d", host, port), done.cause());
  if (connectHandler != null) {
    connectHandler.handle(Future.failedFuture(done.cause()));
}

However, listening to the result of the future for a failure is not possible, because in this case you will also be noted over the closeHandler and the Future. So for some (not for all) condition you might be notified twice for a broken connection.

I think this could be fixed by simply calling the close handler in addition to finishing the Future with a failure in the "if" mentioned above.

[Sammers21]

That is a great idea and as a benefit, it would be way more easy to implement 100% reconnection. But, there is the other side... to call closeHandler when we failed in the attempt to establish TCP connection. I think that it is logical to not call closeHandler when a connection has not been established yet because we have just nothing to close.

[Sammers21]

Btw, @ppatierno, what do you think about it?

[ctron]

Well if you don't call the closeHandler when it was not connected, then you can't implement re-connect that way. But if you always do call the closeHandler, then you can check locally (in your state) if you had a successful connection before.

The most important thing might be some proper documentation in the javadoc to explain this. If this is all that it needs, I am happy to amend the PR for more documentation.

[vietj]

keep in mind that Vert.x NetClient already supports connect retries when the connection fails (not when it is disconnected as this is protocol related)

[ctron]

But I did understand @Sammers21 that this is not supported with the MQTT client.

[ppatierno]

At TCP level the retries on connection failures work (thanks to the underlying NetClient). If you set the reconnectAttempts in the MqttClientOptions and try to connect to the server when it's not listening at all, you can see the SYN RST ACK sequence more times (the number of attempts) so it means that the NetClient is re-trying connection at TCP level. I guess that what you want is a reconnection when the already established connection with the server is closed (for some reason) and a new one should be established. Is that right ? It is something different from the reconnectAttempts feature.

[vietj]

@ppatierno that's my opinion too, reconnection on an established socket is only possible if it makes sense for the protocol, I don't know about MQTT

[ctron]

As a user of MQTTClient I don't want to distinguish between TCP and MQTT layer when I configure reconnect. If my desire is to "keep the MQTT connection open", then I would expect the client to take care of that and re-establish a connection on the TCP and MQTT layer for me.

If that is not supported by the MQTTClient (which is ok to me), then I would expect the documentation of setReconnectAttempts to be different (currently: "Set the value of reconnect attempts") to reflect that this is "just" the initial TCP connection.

However I don't see a real benefit to only implement re-connect for the initial TCP open and leave the MQTT re-connect to the user.

[ppatierno]

@ctron I totally agree with you. The re-connect feature at TCP level comes from the underlying NetClient so it was already there. The current MQTTClient doesn't provide an out-of-box reconnect feature and I agree that it's a missing point. What do you think if I close this issue and open a new issure related to develop such a missing feature (I'll reference the current issue from there then).

[vietj]

that being said, it could be simply implemented with a close handler that reconnects when it is called.

[ppatierno]

@vietj this is what @ctron is trying to achive but even providing the #69 PR because the closeHandler isn't called when TCP connection isn't established. I have some doubts about that for the meaning of the closeHandler ... a connection was closed which is not true when a connection isn't established.

[vietj]

I think that you don't need to do that, because vertx NetClient already takes care of re-connect failures, so you only need to handle the case when the connection is closed after being established

[vietj]

overall I'm wondering if that would not make sense to have an MQTT connection pool that would perform reconnect in such situations

[ppatierno]

It's clear that it's not an issue but just a missing feature, I'm going to close this one.

[abccbaandy]

I think reconnect is a important feature, and not just for reconnect, we need resubscribe feature too.

[abccbaandy]

But I know it's a miss feature in most of mqtt component :P

for ex:
https://issues.apache.org/jira/browse/CAMEL-11691