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.

Sign up for GitHub

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

Jump to bottom

Remove support for address resolving in InetSocketTransportAddress #13014

Closed
s1monw opened this issue Aug 20, 2015 · 4 comments
Closed

Remove support for address resolving in InetSocketTransportAddress #13014

s1monw opened this issue Aug 20, 2015 · 4 comments
Labels
>enhancement v2.0.0-beta1

Comments

@s1monw
Copy link
Contributor

s1monw commented Aug 20, 2015

We shouldn't do any hostname resolving inside ES even though it's disabled by default we should't do it at all. it's simpler and more reliable to just use IPs. This will essentially remove network.address.serialization.resolve which is false by default.

this is a followup from #12999
s1monw added a commit to s1monw/elasticsearch that referenced this issue Aug 20, 2015
@s1monw
Remove support for address resolving in InetSocketTransportAddress
214d303 
this commit removes all support for reverse host name resolving from
InetSocketTransportAddress. This class now only returns IP addresses.

Closes elastic#13014
@s1monw s1monw mentioned this issue Aug 20, 2015
Merged
@kenden
Copy link

kenden commented Aug 25, 2015

Hi @s1monw,
Could you explain why we shouldn't do any hostname resolving inside ES?
What if we use for example AWS Route53 to point to the IP of an Elasticsearch cluster?
(Ex: "myaddress.myserver. -> 10.0.10.51)
If the IP address is changed to, say 10.0.10.59, AWS clients will still be trying to access the old IP address and get a NoNodeAvailableException.

@s1monw
Copy link
Contributor Author

s1monw commented Aug 25, 2015

Could you explain why we shouldn't do any hostname resolving inside ES?
What if we use for example AWS Route53 to point to the IP of an Elasticsearch cluster?
(Ex: "myaddress.myserver. -> 10.0.10.51)
If the IP address is changed to, say 10.0.10.59, AWS clients will still be trying to access the old IP address and get a NoNodeAvailableException.

sorry I don't understand what you are referring to. This change disables the potential reverse lookup for IP -> hostname that we do to render nodestats etc. I don't think this will affect transport clients?

@kenden
Copy link

kenden commented Aug 25, 2015

But don't we use InetSocketTransportAddress to set up a TransportClient?
https://www.elastic.co/guide/en/elasticsearch/client/java-api/current/transport-client.html
Sorry if I'm getting this wrong. This seems related to this issue:
#10337

@s1monw
Copy link
Contributor Author

s1monw commented Aug 27, 2015

But don't we use InetSocketTransportAddress to set up a TransportClient?

so to be clear the change here is what is default in previous version of elasticsearch. We never lookup the hostname from the IP. for the transport client you should be all fine here but nodes in the cluster might be different. the node will likely drop out of the cluster and then rejoin with the new IP? to enable that host name resolution you had to enable an undocumented setting so I don't think it's really changing anything for you?

kovrus added a commit to crate/crate that referenced this issue Jul 15, 2016
@kovrus
resolve hostname for the hostname column in sys.nodes
68d1949 
it was previously done in ES, but removed after
ES 2.0.0
elastic/elasticsearch#13014
kovrus added a commit to crate/crate that referenced this issue Jul 15, 2016
@kovrus
resolve hostname for the hostname column in sys.nodes
ee15c21 
it was previously done in ES, but removed after
ES 2.0.0
elastic/elasticsearch#13014
kovrus added a commit to crate/crate that referenced this issue Jul 15, 2016
@kovrus
resolve hostname for the hostname column in sys.nodes
581c77f 
The host name resolution was previously done in
InetSocketTransportAddres, but removed after ES 2.0.0.

elastic/elasticsearch#13014
kovrus added a commit to crate/crate that referenced this issue Jul 15, 2016
@kovrus
resolve hostname for the hostname column in sys.nodes
206b9d8 
The host name resolution was previously done in
InetSocketTransportAddres, but removed after ES 2.0.0.

elastic/elasticsearch#13014
kovrus added a commit to crate/crate that referenced this issue Jul 15, 2016
@kovrus
resolve hostname for the hostname column in sys.nodes
ee66979 
The host name resolution was previously done in
InetSocketTransportAddres, but removed after ES 2.0.0.

elastic/elasticsearch#13014
kovrus added a commit to crate/crate that referenced this issue Jul 15, 2016
@kovrus
resolve hostname for the hostname column in sys.nodes
6066a90 
The host name resolution was previously done in
InetSocketTransportAddres, but removed after ES 2.0.0.

elastic/elasticsearch#13014
@kovrus kovrus mentioned this issue Jul 15, 2016
Merged
kovrus added a commit to crate/crate that referenced this issue Jul 15, 2016
@kovrus
resolve hostname for the hostname column in sys.nodes
da3e6d8 
The host name resolution was previously done in
InetSocketTransportAddres, but removed after ES 2.0.0.

elastic/elasticsearch#13014
kovrus added a commit to crate/crate that referenced this issue Jul 15, 2016
@kovrus
resolve hostname for the hostname column in sys.nodes
4022168 
The host name resolution was previously done in
InetSocketTransportAddres, but removed after ES 2.0.0.

elastic/elasticsearch#13014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
>enhancement v2.0.0-beta1
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@clintongormley @kenden @s1monw