Hello,
I am using automaticReconnectWithDefaultConfig() and mqttConnectTimeout() like this:
First I create transport config with connectTimeout
transportConfigWss = MqttClientTransportConfig.builder() //
.serverAddress(new InetSocketAddress(rabbitConnectionDetail.getHostname(), rabbitConnectionDetail.getRabbitPortMqttWss())) //
.mqttConnectTimeout(rabbitConnectionDetail.getMqttConnectionTimeoutSeconds() * 1000L, TimeUnit.MILLISECONDS) //
.webSocketConfig(ws) //
.sslConfig(sslConfig) //
.build();
then I apply automaticReconnectWithDefaultConfig and the transportConfig with mqttConnectTimeout
Mqtt3Client.builder() //
.automaticReconnectWithDefaultConfig() //
.addConnectedListener(context -> LOG.info("MQTT WSS HIVE " + clientType.toUpperCase() + " CONNECTED.")) //
.addDisconnectedListener(context -> {
final Throwable cause = context.getCause();
if (cause instanceof Mqtt3ConnAckException)
{
LOG.warn("MQTT WSS HIVE " + clientType + " NOT CONNECTED. BECAUSE OF NEGATIVE CONNACK WITH CODE " + ((Mqtt3ConnAckException) cause).getMqttMessage().getReturnCode());
}
else if (cause instanceof Mqtt3DisconnectException)
{
LOG.warn("MQTT WSS HIVE DISCONNECTED WITH A DISCONNECT");
}
else
{
LOG.warn("MQTT WSS HIVE DISCONNECTED: BECAUSE OF " + cause.getMessage().toUpperCase());
}
}) //
.identifier(identifier) //
.transportConfig(transportConfigWss) //
.simpleAuth() //
.username(rabbitConnectionDetail.getUsername()) //
.password(rabbitConnectionDetail.getPassword().getBytes(StandardCharsets.UTF_8)) //
.applySimpleAuth() //
.buildAsync();
My first problem is the connection timeout. I thought that it defines the maximum time interval the client will wait for the network connection to the MQTT server to be established.
My log when trying to establish the connection, to a server which is not running, having the connection timeout set at 30 seconds, looks like this:
10:21:09 → first entry CLOSEDCHANNELEXCEPTION
10:23:11 → I dont know if OK. The first connect above 30 seconds after previous
10:25:33 → definitely not OK. I thought that the client will not try to reconnect anymore because it is more than 30 second from row above
My other problem is the automatic reconnect when I start the server, create connection and stop the server my backoff between reconnects goes far beyond the max of 2 minutes between the last but one and the last try. My expectation was that once two reconnects reach a bigger interval than 2 minutes the client will not be reconnecting anymore.
My reconnects which are around 2 mins between each other are as follows:
10:04:04
10:05:44 → OK, less than 2 mins after previous
10:08:05 → I dont know if OK. The first reconnect above 2 mins after previous
10:10:28 → definitely not OK. I thought that the client will not try to reconnect anymore because it is more than 2 mins from row above
10:12:03 → definitely not OK, previous entry was already after 2 mins from preceding one and interestingly the duration between attempts decreased
Would you help please reaching the code when my client will try to create the initial connection for as long as defined by the .mqttConnectTimeout() and reconnect when it looses the connection for as long as defined by the automaticReconnectWithDefaultConfig() - max 2 mins? Thank you for your efforts!
EDITED:
I just came to another idea. How is the retry policy handled for the initial connect? What happens if the initial connect fails (having max connection timeout at 30 seconds?). Does some auto-reconnect policy kick in, or do I write my own code?
I can not test this, because the above mentioned does not work and the client simply keeps on trying even though the 30 second from connectionTimeout passed… Thank you!
EDIT OF EDIT 
I found a project on github where they dont use mqttConnectTimeout. They only use
automaticReconnect()//
.initialDelay(20, TimeUnit.SECONDS)//
.maxDelay(20, TimeUnit.SECONDS)//
.applyAutomaticReconnect() //
Even though the initial connection is not established within 30 seconds, it is constantly retried according to setting above (as if the set value would be 0). Which is actually better for me. But I was kind of expecting it would after 30 seconds result in no more tries.