Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

slaupster
Copy link

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.

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.
@slaupster
Copy link
Author

Not sure if there is a delay but I've signed the CLA and had what appears to be confirmation.

@clintongormley clintongormley added the :Core/Infra/Transport API Transport client API label May 25, 2015
@clintongormley
Copy link

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?

@spinscale
Copy link
Contributor

@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.

@mirekingr
Copy link

This bug fix looks quite useful, any plans to release it?

@dakrone
Copy link
Member

dakrone commented Apr 6, 2016

@spinscale revisiting this, do you still think it's a good idea? Does it need another review?

@spinscale
Copy link
Contributor

@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

@dakrone
Copy link
Member

dakrone commented Sep 12, 2016

@spinscale any update on this?

@rjernst
Copy link
Member

rjernst commented Jun 9, 2017

We should make a decision on this PR as it has been open for over 2 years. I have marked it for discussion.

@elasticmachine
Copy link
Collaborator

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?

@rjernst rjernst added the discuss label Jun 9, 2017
@dakrone
Copy link
Member

dakrone commented Aug 15, 2017

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)

@dakrone dakrone closed this Aug 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants