# Client Recovery **URL:** \ **Category:** Elasticsearch\ **Created:** [August 16, 2011, 7:26pm UTC](https://discuss.elastic.co/t/client-recovery/5176 "2011-08-16T19:26:33Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![James\_Cook](https://avatars.discourse-cdn.com/v4/letter/j/898d66/32.png) [@James\_Cook](https://discuss.elastic.co/u/James_Cook)\ **Post date:** [August 16, 2011, 7:26pm UTC](https://discuss.elastic.co/t/client-recovery/5176/1 "2011-08-16T19:26:33Z")
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? ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [August 16, 2011, 11:44pm UTC](https://discuss.elastic.co/t/client-recovery/5176/2 "2011-08-16T23:44:30Z")
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](mailto: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? ---
**Author:** ![James\_Cook](https://avatars.discourse-cdn.com/v4/letter/j/898d66/32.png) [@James\_Cook](https://discuss.elastic.co/u/James_Cook)\ **Post date:** [August 17, 2011, 12:54am UTC](https://discuss.elastic.co/t/client-recovery/5176/3 "2011-08-17T00:54:11Z")
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? ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [August 17, 2011, 1:56am UTC](https://discuss.elastic.co/t/client-recovery/5176/4 "2011-08-17T01:56:26Z")
On Wed, Aug 17, 2011 at 3:54 AM, James Cook [jcook@tracermedia.com](mailto: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. ---
**Author:** ![James\_Cook](https://avatars.discourse-cdn.com/v4/letter/j/898d66/32.png) [@James\_Cook](https://discuss.elastic.co/u/James_Cook)\ **Post date:** [August 17, 2011, 2:21am UTC](https://discuss.elastic.co/t/client-recovery/5176/5 "2011-08-17T02:21:50Z")
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](https://github.com/elasticsearch/elasticsearch/issues/1062) Is there an issue implementing this feature that makes it problematic? ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [August 17, 2011, 3:40am UTC](https://discuss.elastic.co/t/client-recovery/5176/6 "2011-08-17T03:40:50Z")
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](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](mailto: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](https://github.com/elasticsearch/elasticsearch/issues/1062) > > Is there an issue implementing this feature that makes it problematic? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 3:56am UTC](https://discuss.elastic.co/t/client-recovery/5176/7 "2017-07-06T03:56:48Z")