Can the ES client wait until the ES server hostname resolves?

Hi, I'm using Elasticsearch (ES) and Docker-Compose. Sometimes the ES Docker Container hasn't yet started, when my main container (the one that runs my code and connects to ES) starts. Then InetAddress.getByName("search") below throws a (because Docker's DNS server hasn't yet assigned an IP address to the search container, as far as I've understood).

I would like ES to repeatedly try to [resolve the hostname of the ES Docker container], and, eventually, when the name resolves, connect to the host.

I didn't find any built-in functionality for this (in ES 5 alpha 3). I'm getting the impression that ES wants an IP number always, and doesn't work with hostnames at all: all examples I found use InetAddress.getByName and passes the result to ES.

  1. Is there any way to have the ES client resolve the host, and politely wait until the hostname resolves to an IP number?

Also, if the ES server suddenly disappears, then, when the client attempts to reconnect, if now again the DNS server cannot resolve the address, the client ought to wait until the hostname resolves, and then continue with attempting to reconnect.

  1. Do any other people have this same situation? What did you do?

I suppose I can write my own appserver logic that won't create the ES client before the ES server hostname resolves. But I'd rather not :- )

This is my code, and getByName throws the UnknownHostException:

val elasticSearchClient = es.client.transport.TransportClient.builder().build()
      new es.common.transport.InetSocketTransportAddress("search"), 9300))

(I hope all this is understandable :- ))

Best regards,

No. This is not an ES issue; ES assumes full functioning and properly configured network. You should solve that in docker-compose. If not possible, write a shell script that waits for the network. If that is also not possible, roll your own Java code, and use a loop-controlled InetAdress.isReachable() before starting the ES client.

All ES clients have a failover mechanism implemented. ES does not make a difference between DNS server failure, network failure, or node failure. If failover is not possible because all ES nodes are controlled by a single DNS which fails, it is considered fatal - the ES client will stop to work and throw exceptions after a timeout.

1 Like

Thanks, that was lots of useful info.

(In my particular case, this won't work: "write a shell script that waits for the network" because the app server should start directly, without waiting for ES. It's OK if search is unavailable for a short while. Docker-Compose does have built in functionality for starting things in the correct order, but it doesn't know how long it should wait in between each container it starts (it doesn't know when the services inside, are ready). So I'll write Scala code to deal with all this.)