You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: