New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Continually try to resolve a host that is unresolved #11256
Conversation
This is a basic fix for the issue described in logstash-plugins/logstash-output-elasticsearch#131 I'm not sure this behaviour is desirable as a default or whether it would make sense to honor Java's networkaddress.cache.ttl and networkaddress.cache.negative.ttl or make ES specific properties.
Not sure if there is a delay but I've signed the CLA and had what appears to be confirmation. |
Hi @slaupster Thanks for the PR (and I can see that you have signed the CLA, thanks). I wonder if this fix is sufficient. As I understand it, Elasticsearch will never re-resolve DNS entries, so if the IP for a node changes, the only way to make the transport client resolve the IP address again is to restart it. Wondering if we can improve this logic somehow. @spinscale what do you think? |
@clint you're right, we already had a couple of discussions about this, see here. Especially, once an IP address is part of the cluster state (like as part of a client node), dynamic changes are more tricky, as we do not serialize the current ip address over the wire. In the case of using a TransportClient though, I could imagine the above change. |
This bug fix looks quite useful, any plans to release it? |
@spinscale revisiting this, do you still think it's a good idea? Does it need another review? |
@dakrone yes, I still think the change is useful for transport clients, however logstash is not affected by this due to using HTTP now. It does need another review, I did not follow any recent changes about networking code |
@spinscale any update on this? |
We should make a decision on this PR as it has been open for over 2 years. I have marked it for discussion. |
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
I'm going to close this since there has been no update and Logstash no longer uses the Transport client (the underlying issues has been closed as well) |
This is a basic fix for the issue described in logstash-plugins/logstash-output-elasticsearch#131
I'm not sure this behaviour is desirable as a default or whether it would make sense to honor Java's networkaddress.cache.ttl and networkaddress.cache.negative.ttl or make ES specific properties.