Elastisch High Availability client tips?

[Dave Tenny]

I'm prototyping some code for elasticsearch use in a product and using elastisch (so far).

I have not done my homework yet for anything HA related but I know I need to set it up, and while playing with the elastisch client I noticed one thing that surprised me, namely, that a call to 'connect' appears to be lazy.  E.g.

(defonce conn (es/connect [[el-host 9300]] {"cluster.name" cluster-name}))

This was just for playing around.  One time I executed the code but had no ES server running, and there was no error whatsoever by the connect call. 

1. Should the connect have failed suine the host was unreachable?
2. Since the connect did not fail, does that mean we're not really keeping a connection open to the ES node between client API calls on the connection, and therefore paying a performance penalty?
3. Does a real connection established on the first API activity that requires it cause a persistent connection to be open?
4. Once a persistent connection is open what is the proper technique for detecting connection failure and redirecting the connection to an alternate ES node?

Tips appreciated, thanks.

[Michael Klishin]

 On 19 Oct 2015 at 20:22:36, Dave Tenny (dave....@gmail.com) wrote:
> This was just for playing around. One time I executed the code
> but had no ES server running, and there was no error whatsoever
> by the connect call.

Connect is not lazy. I’m not sure if you’ve actually called defonce
but it only evaluates once, as the name suggests.
--
@michaelklishin, github.com/michaelklishin

[Dave Tenny]

Something about the connection is definitely lazy. In the following REPL sequence you can see that I can call 'connect' and get a TransportClient even though the server is down.

No *actual* connection occurs until I attempt an API call that uses the TransportClient objects.

This was why I asked my original questions about whether we're really retaining the connection and what HA tips people might have about failover when an ES node goes down

(i.e. how TransportClient handles it, what I need to do to make it work, etc).

elcl.core> conn
CompilerException java.lang.RuntimeException: Unable to resolve symbol: conn in this context, compiling:(/tmp/form-init180237287492528905.clj:1:4464)
elcl.core> ;; ES is not running
elcl.core> (defonce conn (es/connect [["localhost" 9300]] {"cluster.name" "jdt-es-cluster"}))
#'elcl.core/conn
elcl.core> conn
#object[org.elasticsearch.client.transport.TransportClient 0x6afde272 "org.elasticsearch.client.transport.TransportClient@6afde272"]
elcl.core> (keys (.getIndices (esi/stats conn)))
NoNodeAvailableException None of the configured nodes are available: []  org.elasticsearch.client.transport.TransportClientNodesService.ensureNodesAreAvailable (TransportClientNodesService.java:305)
elcl.core> ;; start ES server
elcl.core> (keys (.getIndices (esi/stats conn)))
(".kibana" "de_index")

[Michael Klishin]

On 20 Oct 2015 at 13:50:07, Dave Tenny (dave....@gmail.com) wrote:
> Something about the connection is definitely lazy. In the following
> REPL sequence you can see that I can call 'connect' and get a TransportClient
> even though the server is down.

Elastisch’s connection code is not lazy. The underlying transport client can be,
or perhaps it keeps trying to connect instead of throwing an exception immediately.
--
@michaelklishin, github.com/michaelklishin