With the 2.0.2 client, when http is being used it seems that every flush instantiates a new connection. This makes sense and therefore does not require any "reconnection" methodology. However, if a dns resolution failure occurs once, then for the life of the Sender it will no longer attempt to resolve.
Specifically, there is a scenario where when a pc boots, a service we use for networking may not be connected yet. In this case, dns resolution may fail for 30 seconds or so. However, if the Sender has been created and a flush already called then it seems the DNS failure is in someway cached and it never is attempting to resolve the dns again. This is the error I received:
questdb.ingress.IngressError: Could not flush buffer: http://kronus-nexus:4900/write?precision=n: Dns Failed: resolve dns name 'kronus-nexus:4900': failed to lookup address information: Temporary failure in name resolution
Then, for the life of the code, it keeps having the same error and is never able to reconnect again. But then if I change nothing but just restart the code, then dns resolves just fine and everything works as intended. Also, if I change the address to a hard coded ip, then it will also auto connect after the network service is up and runs just fine. This is a working solution for me for now but it does not seem intended that a single dns failure will result in a Sender that is forever in a failure state.
With the 2.0.2 client, when http is being used it seems that every flush instantiates a new connection. This makes sense and therefore does not require any "reconnection" methodology. However, if a dns resolution failure occurs once, then for the life of the Sender it will no longer attempt to resolve.
Specifically, there is a scenario where when a pc boots, a service we use for networking may not be connected yet. In this case, dns resolution may fail for 30 seconds or so. However, if the Sender has been created and a flush already called then it seems the DNS failure is in someway cached and it never is attempting to resolve the dns again. This is the error I received:
Then, for the life of the code, it keeps having the same error and is never able to reconnect again. But then if I change nothing but just restart the code, then dns resolves just fine and everything works as intended. Also, if I change the address to a hard coded ip, then it will also auto connect after the network service is up and runs just fine. This is a working solution for me for now but it does not seem intended that a single dns failure will result in a Sender that is forever in a failure state.