# Transport client sniff - AWS **URL:** \ **Category:** Elasticsearch\ **Created:** [June 9, 2011, 11:54pm UTC](https://discuss.elastic.co/t/transport-client-sniff-aws/4594 "2011-06-09T23:54:22Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Pat\_Christopher](https://avatars.discourse-cdn.com/v4/letter/p/f14d63/32.png) [@Pat\_Christopher](https://discuss.elastic.co/u/Pat_Christopher)\ **Post date:** [June 9, 2011, 11:54pm UTC](https://discuss.elastic.co/t/transport-client-sniff-aws/4594/1 "2011-06-09T23:54:22Z")
Hello, Version: 0.16.2, client and server I'm trying to use the transport client's sniff while accessing a cluster. I'm hitting the following two issues: 1. when running with the cluster in the cloud (AWS ec2), I am unable to connect with client.transport.sniff set to true. there is no exception thrown at runtime, it doesn't populate the nodelist if I remove this setting, it connects as expected. if I run with the cluster running locally, my client connects and lists all nodes in the cluster do I need to specify something specifically for sniff to work in a cloud env? 1. running with sniff set to true does not provide a durable connection if the discovery node is killed if I connect to a running cluster with sniff set to true, wait for the client to find all nodes in the cluster then terminate the original node, the client loses its connection. I expected the connection to fail over to one of the sniffed addresses. if I list two nodes explicitly, I can terminate either of the two listed nodes and remain connected to the cluster ``` I'm not sure if the Transport.Client is supposed to remain ``` connected if the single discovery node is termed, but it seems like it could. Thanks, Pat ---
**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:** [June 10, 2011, 12:23am UTC](https://discuss.elastic.co/t/transport-client-sniff-aws/4594/2 "2011-06-10T00:23:03Z")
When using sniff, the address used to connect to the nodes being added is the "publish\_address" (for transport) they start with (while with a non sniff option, its the address you specify). Maybe there is a problem with the publish address that got decided for the nodes (you can see it logged when a node starts up). Yea, sniff will always rely on the seed of addresses you specify, and if all nodes are down, then nothing will be "sniffed". It can be enhanced to try and use sniffed nodes in this case, and continue to try and figure out the cluster. Shouldn't be too difficult to implement if you are up to it (check TransportClientNodesService). pull requests are welcomed 🙂 -shay.banon On Friday, June 10, 2011 at 2:54 AM, Pat Christopher wrote: > Hello, > Version: 0.16.2, client and server > > I'm trying to use the transport client's sniff while accessing a > cluster. I'm hitting the following two issues: > > 1. when running with the cluster in the cloud (AWS ec2), I am unable > to connect with client.transport.sniff set to true. there is no > exception thrown at runtime, it doesn't populate the nodelist > if I remove this setting, it connects as expected. > if I run with the cluster running locally, my client connects and > lists all nodes in the cluster > > do I need to specify something specifically for sniff to work in a > cloud env? > > 1. running with sniff set to true does not provide a durable > connection if the discovery node is killed > if I connect to a running cluster with sniff set to true, wait for > the client to find all nodes in the cluster then terminate the > original node, the client loses its connection. I expected the > connection to fail over to one of the sniffed addresses. > if I list two nodes explicitly, I can terminate either of the two > listed nodes and remain connected to the cluster > > I'm not sure if the Transport.Client is supposed to remain > connected if the single discovery node is termed, but it seems like it > could. > > Thanks, > Pat ---
**Author:** ![Pat\_Christopher](https://avatars.discourse-cdn.com/v4/letter/p/f14d63/32.png) [@Pat\_Christopher](https://discuss.elastic.co/u/Pat_Christopher)\ **Post date:** [June 10, 2011, 12:35am UTC](https://discuss.elastic.co/t/transport-client-sniff-aws/4594/3 "2011-06-10T00:35:44Z")
ES is binding the publish\_address to the AWS internal ip, which I can't connect to from my local machine. I'll try my next test from an AWS node. On my list! I'll take a look at the TransportClientNodesService tomorrow. Thanks, Pat On Jun 9, 5:23 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote: > When using sniff, the address used to connect to the nodes being added is the "publish\_address" (for transport) they start with (while with a non sniff option, its the address you specify). Maybe there is a problem with the publish address that got decided for the nodes (you can see it logged when a node starts up). > > Yea, sniff will always rely on the seed of addresses you specify, and if all nodes are down, then nothing will be "sniffed". It can be enhanced to try and use sniffed nodes in this case, and continue to try and figure out the cluster. Shouldn't be too difficult to implement if you are up to it (check TransportClientNodesService). pull requests are welcomed 🙂 > > -shay.banon > > On Friday, June 10, 2011 at 2:54 AM, Pat Christopher wrote: > > > Hello, > > Version: 0.16.2, client and server > > > I'm trying to use the transport client's sniff while accessing a > > cluster. I'm hitting the following two issues: > > > > 1. when running with the cluster in the cloud (AWS ec2), I am unable > > to connect with client.transport.sniff set to true. there is no > > exception thrown at runtime, it doesn't populate the nodelist > > if I remove this setting, it connects as expected. > > if I run with the cluster running locally, my client connects and > > lists all nodes in the cluster > > > do I need to specify something specifically for sniff to work in a > > cloud env? > > > 1. running with sniff set to true does not provide a durable > > connection if the discovery node is killed > > if I connect to a running cluster with sniff set to true, wait for > > the client to find all nodes in the cluster then terminate the > > original node, the client loses its connection. I expected the > > connection to fail over to one of the sniffed addresses. > > if I list two nodes explicitly, I can terminate either of the two > > listed nodes and remain connected to the cluster > > > I'm not sure if the Transport.Client is supposed to remain > > connected if the single discovery node is termed, but it seems like it > > could. > > > Thanks, > > Pat ---
**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:** [June 10, 2011, 12:37am UTC](https://discuss.elastic.co/t/transport-client-sniff-aws/4594/4 "2011-06-10T00:37:48Z")
Right, that was the main reason why the non sniff option is there at all, to allow for you on the client code to control the IPs to connect to without "sniffing". On Friday, June 10, 2011 at 3:35 AM, Pat Christopher wrote: > ES is binding the publish\_address to the AWS internal ip, which I > can't connect to from my local machine. I'll try my next test from an > AWS node. > > On my list! I'll take a look at the TransportClientNodesService > tomorrow. > > Thanks, > Pat > > On Jun 9, 5:23 pm, Shay Banon \<[shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) ([http://elasticsearch.com](http://elasticsearch.com))\> wrote: > > > When using sniff, the address used to connect to the nodes being added is the "publish\_address" (for transport) they start with (while with a non sniff option, its the address you specify). Maybe there is a problem with the publish address that got decided for the nodes (you can see it logged when a node starts up). > > > > Yea, sniff will always rely on the seed of addresses you specify, and if all nodes are down, then nothing will be "sniffed". It can be enhanced to try and use sniffed nodes in this case, and continue to try and figure out the cluster. Shouldn't be too difficult to implement if you are up to it (check TransportClientNodesService). pull requests are welcomed 🙂 > > > > -shay.banon > > > > On Friday, June 10, 2011 at 2:54 AM, Pat Christopher wrote: > > > > > Hello, > > > Version: 0.16.2, client and server > > > > > I'm trying to use the transport client's sniff while accessing a > > > cluster. I'm hitting the following two issues: > > > > > > 1. when running with the cluster in the cloud (AWS ec2), I am unable > > > to connect with client.transport.sniff set to true. there is no > > > exception thrown at runtime, it doesn't populate the nodelist > > > if I remove this setting, it connects as expected. > > > if I run with the cluster running locally, my client connects and > > > lists all nodes in the cluster > > > > > do I need to specify something specifically for sniff to work in a > > > cloud env? > > > > > 1. running with sniff set to true does not provide a durable > > > connection if the discovery node is killed > > > if I connect to a running cluster with sniff set to true, wait for > > > the client to find all nodes in the cluster then terminate the > > > original node, the client loses its connection. I expected the > > > connection to fail over to one of the sniffed addresses. > > > if I list two nodes explicitly, I can terminate either of the two > > > listed nodes and remain connected to the cluster > > > > > I'm not sure if the Transport.Client is supposed to remain > > > connected if the single discovery node is termed, but it seems like it > > > could. > > > > > Thanks, > > > Pat ---
**Author:** ![Pat\_Christopher](https://avatars.discourse-cdn.com/v4/letter/p/f14d63/32.png) [@Pat\_Christopher](https://discuss.elastic.co/u/Pat_Christopher)\ **Post date:** [June 10, 2011, 12:43am UTC](https://discuss.elastic.co/t/transport-client-sniff-aws/4594/5 "2011-06-10T00:43:43Z")
Makes sense. I tried this again from an AWS node, all nodes in cluster found and correctly printed out by the client. thanks again, Pat On Jun 9, 5:37 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote: > Right, that was the main reason why the non sniff option is there at all, to allow for you on the client code to control the IPs to connect to without "sniffing". > > On Friday, June 10, 2011 at 3:35 AM, Pat Christopher wrote: > > > ES is binding the publish\_address to the AWS internal ip, which I > > can't connect to from my local machine. I'll try my next test from an > > AWS node. > > > On my list! I'll take a look at the TransportClientNodesService > > tomorrow. > > > Thanks, > > Pat > > > On Jun 9, 5:23 pm, Shay Banon \<[shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) ([http://elasticsearch.com](http://elasticsearch.com))\> wrote: > > > > > When using sniff, the address used to connect to the nodes being added is the "publish\_address" (for transport) they start with (while with a non sniff option, its the address you specify). Maybe there is a problem with the publish address that got decided for the nodes (you can see it logged when a node starts up). > > > > Yea, sniff will always rely on the seed of addresses you specify, and if all nodes are down, then nothing will be "sniffed". It can be enhanced to try and use sniffed nodes in this case, and continue to try and figure out the cluster. Shouldn't be too difficult to implement if you are up to it (check TransportClientNodesService). pull requests are welcomed 🙂 > > > > -shay.banon > > > > On Friday, June 10, 2011 at 2:54 AM, Pat Christopher wrote: > > > > > > > Hello, > > > > Version: 0.16.2, client and server > > > > > I'm trying to use the transport client's sniff while accessing a > > > > cluster. I'm hitting the following two issues: > > > > > > > > 1. when running with the cluster in the cloud (AWS ec2), I am unable > > > > to connect with client.transport.sniff set to true. there is no > > > > exception thrown at runtime, it doesn't populate the nodelist > > > > if I remove this setting, it connects as expected. > > > > if I run with the cluster running locally, my client connects and > > > > lists all nodes in the cluster > > > > > do I need to specify something specifically for sniff to work in a > > > > cloud env? > > > > > 1. running with sniff set to true does not provide a durable > > > > connection if the discovery node is killed > > > > if I connect to a running cluster with sniff set to true, wait for > > > > the client to find all nodes in the cluster then terminate the > > > > original node, the client loses its connection. I expected the > > > > connection to fail over to one of the sniffed addresses. > > > > if I list two nodes explicitly, I can terminate either of the two > > > > listed nodes and remain connected to the cluster > > > > > I'm not sure if the Transport.Client is supposed to remain > > > > connected if the single discovery node is termed, but it seems like it > > > > could. > > > > > Thanks, > > > > Pat ---
**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, 4:04am UTC](https://discuss.elastic.co/t/transport-client-sniff-aws/4594/6 "2017-07-06T04:04:05Z")