# 0.14.2 TransportClient does not appear to be honoring cluster name? **URL:** \ **Category:** Elasticsearch\ **Created:** [January 19, 2011, 6:01pm UTC](https://discuss.elastic.co/t/0-14-2-transportclient-does-not-appear-to-be-honoring-cluster-name/3811 "2011-01-19T18:01:07Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![ppearcy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ppearcy/32/980_2.png) [@ppearcy](https://discuss.elastic.co/u/ppearcy)\ **Post date:** [January 19, 2011, 6:01pm UTC](https://discuss.elastic.co/t/0-14-2-transportclient-does-not-appear-to-be-honoring-cluster-name/3811/1 "2011-01-19T18:01:07Z")
I'm using the code below to create transport clients and verify that all nodes are in sync with what they see. Basically, a poor mans split cluster check. However, it does not appear the 0.14.2 transport client is honoring the cluster name that I have set I would expect the code below to only connect to a cluster named "0.14.2", but it succeeds in connecting to my cluster named "0.13.0". Here is the code: ``` Map m = new HashMap(); m.put("cluster.name","0.14.2"); Settings s = ImmutableSettings.settingsBuilder().put(m).build(); for (String server : servers) { int port = 9300; Client client = new TransportClient(s).addTransportAddress(new ``` InetSocketTransportAddress(server, port)); ``` NodesInfoResponse response = null; try { response = new ``` NodesInfoRequestBuilder(client.admin().cluster()).execute().actionGet(); } catch (NoNodeAvailableException e) {} client.close(); ``` if (response == null) { logger.debug("Unable to retrieve cluster status for " ``` +ESSearcherServer.es.clusterName+ " from: " + server); continue; } ``` // Confirm that Node counts are the same between each client... } ``` I believe this behavior has changed since 0.13, as the 0.13 nodes that are doing checks aren't able to see the 0.14.2 nodes. Thanks! Paul ---
**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:** [January 19, 2011, 7:19pm UTC](https://discuss.elastic.co/t/0-14-2-transportclient-does-not-appear-to-be-honoring-cluster-name/3811/2 "2011-01-19T19:19:27Z")
Heya, Yea, the behavior changed. By default, the transport client does not sniff other nodes in the cluster now, and uses the provided ips to connect to the nodes (and not the publish host ips the nodes are configured with). This make sense when trying to talk to nodes over firewall or that have public and private ip (as in AWS) from outside. To enable the sniff option, and have the transport client sniff out all the nodes in the cluster, set the client.transport.sniff setting to true. This will also do cluster name based filtering. The fact that without sniffing enabled there is no cluster name filtering is a bug. Can you open an issue for this and I will fix it for 0.15? -shay.banon On Wednesday, January 19, 2011 at 8:01 PM, Paul wrote: > I'm using the code below to create transport clients and verify that > all nodes are in sync with what they see. Basically, a poor mans split > cluster check. However, it does not appear the 0.14.2 transport client > is honoring the cluster name that I have set I would expect the code > below to only connect to a cluster named "0.14.2", but it succeeds in > connecting to my cluster named "0.13.0". Here is the code: > > Map\ m = new HashMap\(); > m.put("cluster.name","0.14.2"); > Settings s = ImmutableSettings.settingsBuilder().put(m).build(); > > for (String server : servers) { > int port = 9300; > Client client = new TransportClient(s).addTransportAddress(new > InetSocketTransportAddress(server, port)); > > NodesInfoResponse response = null; > try { > response = new > NodesInfoRequestBuilder(client.admin().cluster()).execute().actionGet(); > } catch (NoNodeAvailableException e) {} > client.close(); > > if (response == null) { > logger.debug("Unable to retrieve cluster status for " > +ESSearcherServer.es.clusterName+ " from: " + server); > continue; > } > > // Confirm that Node counts are the same between each client... > } > > I believe this behavior has changed since 0.13, as the 0.13 nodes that > are doing checks aren't able to see the 0.14.2 nodes. > > Thanks! > Paul ---
**Author:** ![ppearcy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ppearcy/32/980_2.png) [@ppearcy](https://discuss.elastic.co/u/ppearcy)\ **Post date:** [January 19, 2011, 8:20pm UTC](https://discuss.elastic.co/t/0-14-2-transportclient-does-not-appear-to-be-honoring-cluster-name/3811/3 "2011-01-19T20:20:24Z")
Sure thing: > > > The cluster name is no longer honored via the TransportClient unless sniffing is… enable don 0.14.2. See this discussion for more details: > http://elasticsearch-users.115913.n3.nabble.com/0-14-2-TransportClient-does-not-appear-to-be-honoring-cluster-name-tp2289073p2289073.html > > Thanks! Will try out the sniff option and let you know if there are any problems with it. Thanks! On Jan 19, 12:19 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote: > Heya, > > Yea, the behavior changed. By default, the transport client does not sniff other nodes in the cluster now, and uses the provided ips to connect to the nodes (and not the publish host ips the nodes are configured with). This make sense when trying to talk to nodes over firewall or that have public and private ip (as in AWS) from outside. > > To enable the sniff option, and have the transport client sniff out all the nodes in the cluster, set the client.transport.sniff setting to true. This will also do cluster name based filtering. > > The fact that without sniffing enabled there is no cluster name filtering is a bug. Can you open an issue for this and I will fix it for 0.15? > > -shay.banon > > On Wednesday, January 19, 2011 at 8:01 PM, Paul wrote: > > > I'm using the code below to create transport clients and verify that > > all nodes are in sync with what they see. Basically, a poor mans split > > cluster check. However, it does not appear the 0.14.2 transport client > > is honoring the cluster name that I have set I would expect the code > > below to only connect to a cluster named "0.14.2", but it succeeds in > > connecting to my cluster named "0.13.0". Here is the code: > > > Map\ m = new HashMap\(); > > m.put("cluster.name","0.14.2"); > > Settings s = ImmutableSettings.settingsBuilder().put(m).build(); > > > for (String server : servers) { > > int port = 9300; > > Client client = new TransportClient(s).addTransportAddress(new > > InetSocketTransportAddress(server, port)); > > > NodesInfoResponse response = null; > > try { > > response = new > > NodesInfoRequestBuilder(client.admin().cluster()).execute().actionGet(); > > } catch (NoNodeAvailableException e) {} > > client.close(); > > > if (response == null) { > > logger.debug("Unable to retrieve cluster status for " > > +ESSearcherServer.es.clusterName+ " from: " + server); > > continue; > > } > > > // Confirm that Node counts are the same between each client... > > } > > > I believe this behavior has changed since 0.13, as the 0.13 nodes that > > are doing checks aren't able to see the 0.14.2 nodes. > > > Thanks! > > Paul ---
**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:13am UTC](https://discuss.elastic.co/t/0-14-2-transportclient-does-not-appear-to-be-honoring-cluster-name/3811/4 "2017-07-06T04:13:29Z")