Client Recovery

Can someone explain if there is any recovery built into the Transport
client?

If it's connection to a node is broken, what steps does it take to recover?

I ask because the 'client.transport.sniff' property implies the client will
have a broader base of machines to connect to if used. This is either being
done to round-robin requests across the cluster, or to survive a disconnect
to a node in the cluster.

If the client.transport.sniff is used, will the client continue to build out
its list of known cluster members even after initialization?

The transport client will only use the provided list of nodes to build the
list of nodes to use for API calls. There was actually a discussion and a
pull request to basically dynamically grow that list and use it in order to
survive cases where the provided addresses are no longer available, but its
not there yet...

On Tue, Aug 16, 2011 at 10:26 PM, James Cook jcook@tracermedia.com wrote:

Can someone explain if there is any recovery built into the Transport
client?

If it's connection to a node is broken, what steps does it take to
recover?

I ask because the 'client.transport.sniff' property implies the client will
have a broader base of machines to connect to if used. This is either being
done to round-robin requests across the cluster, or to survive a disconnect
to a node in the cluster.

If the client.transport.sniff is used, will the client continue to build
out its list of known cluster members even after initialization?

Yes, that would be a nice feature for those of us whose nodes are
created/destroyed more frequently than a static cluster.

If the Transport client is started in sniff mode, does it end up with a list
of all nodes at the time it connected to the cluster?

If it is connected to one node, and that connection breaks because of a
temporary network hiccup, will it rejoin?

On Wed, Aug 17, 2011 at 3:54 AM, James Cook jcook@tracermedia.com wrote:

Yes, that would be a nice feature for those of us whose nodes are
created/destroyed more frequently than a static cluster.

If the Transport client is started in sniff mode, does it end up with a
list of all nodes at the time it connected to the cluster?

The sniff part end up with a full view of the nodes, yes. But, that full
view is not use for the next "sniff", just the addresses provided when
constructing the transport client.

If it is connected to one node, and that connection breaks because of a
temporary network hiccup, will it rejoin?

Yes, it will reconnect to that node once connection is established.

I was going to add an issue for a Transport Client that keeps building its
knowledge of the cluster over time.

But I saw this
issue: https://github.com/elasticsearch/elasticsearch/issues/1062

Is there an issue implementing this feature that makes it problematic?

The issue you refer to was a bug, not what we are talking about. There is
this pull request:
https://github.com/elasticsearch/elasticsearch/pull/1218that still
requires some more work.

On Wed, Aug 17, 2011 at 5:21 AM, James Cook jcook@tracermedia.com wrote:

I was going to add an issue for a Transport Client that keeps building its
knowledge of the cluster over time.

But I saw this issue:
Transport Client: Adding more nodes causes more scheduled reconnect tasks · Issue #1062 · elastic/elasticsearch · GitHub

Is there an issue implementing this feature that makes it problematic?