Transport Client: get address(es) from settings?

Elastic Stack Elasticsearch
1

Sounds like a newbie-ish kind of question, but I can't find an answer
anywhere. All over the place I'm seeing the following approach used for
pointing a Client at an ES cluster:

new TransportClient(...).addTransportAddress( new
InetSocketTransportAddress( "host", port))

But I'd like to configure the TransportClient entirely from a separate
YAML/JSON. What syntax can I use to express the transport address there, so
that 'new TransportClient(settings)' does the whole thing, without the
hardcoding?

2

Hi Andrew,

Don't take this as the best approach at all but, it worked for me at
least. If someone sees any issue here, please point it out.

Briefly you could use a for loop to iterate for each one of the hosts
defined in your YAML/JSON and call addTransportAddress

Full code here ElasticSearch Client Factory · GitHub

protected static Client createTransportClient(clusterName, port,
hosts, sniffCluster) {
logger.info("Creating Elasticsearch Transport Client for
cluster [$clusterName] and hosts $hosts at port $port")

    Settings settings =

ImmutableSettings.settingsBuilder().put("cluster.name", clusterName)
.put("node.client",
true)
.put("client.transport.sniff",
sniffCluster)
.build()
Client client = new TransportClient(settings)

    hosts.each { host ->
        client.addTransportAddress(new

InetSocketTransportAddress(host, port))
}

    return client
}

On 8 nov, 08:11, Andrew Regan are...@gmail.com wrote:

Sounds like a newbie-ish kind of question, but I can't find an answer
anywhere. All over the place I'm seeing the following approach used for
pointing a Client at an ES cluster:

new TransportClient(...).addTransportAddress( new
InetSocketTransportAddress( "host", port))

But I'd like to configure the TransportClient entirely from a separate
YAML/JSON. What syntax can I use to express the transport address there, so
that 'new TransportClient(settings)' does the whole thing, without the
hardcoding?

3

Hi Frederic,

I've gone with your suggestion - looks like the best option at the moment!

Thanks,

Andrew