MQTT client reconnecting indefinitely, in case of Dynamic DNS record update, because of cached resolved address.

[vvasilevbosch]

🐛 Bug Report

Provided serverAddress in com.hivemq.client.mqtt.MqttClientBuilderBase#serverAddress is cached and reused and does not have expiry. E.g. java.net.InetAddress has epirySet of the resvolde addresses, which by default expires in 30s. This way, if mqtt broker has dynamic DNS, it can happen that dns record is updated with new ip address and the hivemq client tries to reconnect indefinately, which is what happens in our case. To fix it, we provide unresolved address(java.net.InetSocketAddress.createUnresolved), and let the underlying netty dns resolver do the work, but overall this is not handled by the hivemq client.

🔬 How To Reproduce

Steps to reproduce the behavior:

This holds true for both mqtt 3 and mqtt 5 clients, simple way to verify this behaviour is to debug when resolving the address happens - java.net.InetAddress#getAddressesFromNameService, whenever reconnect attempt is done, if the resolved address cache is expired, the address must be looked-up, which does not happen. Reconnecting is done simply by local mosquitto broker that I toggle start/stop.

📈 Expected behavior

The hivemq mqtt client should handle dynamic dns changes and try to re-resolve the address, instead of infinately trying to connect. E.g. store hostname and port, or java.net.URI instead of java.net.InetSocketAddress

📎 Additional context

This behaviour is observed using eclipse ditto's mqtt connection(issue in ditto), with AWS IoT Core, where we got strange disconnects, which from cloud watch logs turned out to be mqtt-keep-alive timouts and were only able to reconnect, if we re-created the mqtt client.