# Transport Client connectedNodes() duplicates **URL:** \ **Category:** Elasticsearch\ **Created:** [September 2, 2014, 2:50am UTC](https://discuss.elastic.co/t/transport-client-connectednodes-duplicates/19564 "2014-09-02T02:50:49Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Stefan\_Will](https://avatars.discourse-cdn.com/v4/letter/s/9dc877/32.png) [@Stefan\_Will](https://discuss.elastic.co/u/Stefan_Will)\ **Post date:** [September 2, 2014, 2:50am UTC](https://discuss.elastic.co/t/transport-client-connectednodes-duplicates/19564/1 "2014-09-02T02:50:49Z")
Hi, for testing purposes, I've started up a stand-alone Elasticsearch node on my laptop, and am using the transport client to connect to it. When I initialize the client using "sniff=true", and then print out the list of connected nodes, as follows: ``` TransportClient client = new TransportClient( ImmutableSettings.builder() .put("client.transport.ignore_cluster_name",true) .put("client.transport.sniff",true) ); client.addTransportAddress(new ``` InetSocketTransportAddress("192.168.1.5",9300)); ``` for(DiscoveryNode node: client.connectedNodes()) { System.out.println(node); } ``` I get two nodes in the output: [#transport#-1][Stefans-MacBook-Pro.local][inet[/192.168.1.5:9300]] [Diablo][15AyTluTS4Wj26tKgkyQDA][Stefans-MacBook-Pro.local][inet[/192.168.1.5:9300]] These are the same node listed twice, presumably once as the node that I added via "addTransportAddress()", and once as sniffed out by the sniffer. You can tell that the latter one is more detailed, and includes the actual node id and name, while the former is just the basic network information. Notice also that they both refer to the same IP and port combination. When I run the same test, but with sniff=false, I get one node, but somewhat surprisingly, the generic "transport" node has been dropped from the list: [Diablo][15AyTluTS4Wj26tKgkyQDA][Stefans-MacBook-Pro.local][inet[/192.168.1.5:9300]] I this the expected behavior ? Why does the sniffer not simply _replace_ the node info like the client does with sniff=false ? Why does it essentially leave the node in there twice, apparently ignoring the fact that there are two entries with the exact same connection info ? I looked at the code, and apparently it dedupes nodes based on ID, which in this case are obviously different (#transport#-1 vs 15AyTluTS4Wj26tKgkyQDA), but ignores the fact that the IP and port are identical. My expectation was that with sniff=true, it would replace the initial with the one sniffed from the cluster, and then add any additional nodes it has discovered, but in reality, I end up with 2x the nodes when I add my entire cluster via addTransportAddress(). Thanks, Stefan -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [September 2, 2014, 5:59am UTC](https://discuss.elastic.co/t/transport-client-connectednodes-duplicates/19564/2 "2014-09-02T05:59:46Z")
Interesting. May be you could open an issue for that? Something like "Transport Client with sniff duplicates nodes"? -- David 😉 Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs Le 2 sept. 2014 à 04:50, Stefan Will [stefan.will@gmail.com](mailto:stefan.will@gmail.com) a écrit : Hi, for testing purposes, I've started up a stand-alone Elasticsearch node on my laptop, and am using the transport client to connect to it. When I initialize the client using "sniff=true", and then print out the list of connected nodes, as follows: ``` TransportClient client = new TransportClient( ImmutableSettings.builder() .put("client.transport.ignore_cluster_name",true) .put("client.transport.sniff",true) ); client.addTransportAddress(new InetSocketTransportAddress("192.168.1.5",9300)); for(DiscoveryNode node: client.connectedNodes()) { System.out.println(node); } ``` I get two nodes in the output: [#transport#-1][Stefans-MacBook-Pro.local][inet[/192.168.1.5:9300]] [Diablo][15AyTluTS4Wj26tKgkyQDA][Stefans-MacBook-Pro.local][inet[/192.168.1.5:9300]] These are the same node listed twice, presumably once as the node that I added via "addTransportAddress()", and once as sniffed out by the sniffer. You can tell that the latter one is more detailed, and includes the actual node id and name, while the former is just the basic network information. Notice also that they both refer to the same IP and port combination. When I run the same test, but with sniff=false, I get one node, but somewhat surprisingly, the generic "transport" node has been dropped from the list: [Diablo][15AyTluTS4Wj26tKgkyQDA][Stefans-MacBook-Pro.local][inet[/192.168.1.5:9300]] I this the expected behavior ? Why does the sniffer not simply _replace_ the node info like the client does with sniff=false ? Why does it essentially leave the node in there twice, apparently ignoring the fact that there are two entries with the exact same connection info ? I looked at the code, and apparently it dedupes nodes based on ID, which in this case are obviously different (#transport#-1 vs 15AyTluTS4Wj26tKgkyQDA), but ignores the fact that the IP and port are identical. My expectation was that with sniff=true, it would replace the initial with the one sniffed from the cluster, and then add any additional nodes it has discovered, but in reality, I end up with 2x the nodes when I add my entire cluster via addTransportAddress(). Thanks, Stefan -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/E8DBD877-D828-44DF-968C-63F6EEDBB247%40pilato.fr](https://groups.google.com/d/msgid/elasticsearch/E8DBD877-D828-44DF-968C-63F6EEDBB247%40pilato.fr). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [September 2, 2014, 5:26pm UTC](https://discuss.elastic.co/t/transport-client-connectednodes-duplicates/19564/3 "2014-09-02T17:26:04Z")
The two nodes are okay. The #transport# node connection on Mac OS X is just using IPv6. ES enumerates all network devices so it finds out about that connection. No need to be concerned, it can be configured if you want that, either by JVM property, or by elasticsearch settings in config for the network module. > **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)** > > Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today. Jörg On Tue, Sep 2, 2014 at 4:50 AM, Stefan Will [stefan.will@gmail.com](mailto:stefan.will@gmail.com) wrote: > Hi, > > for testing purposes, I've started up a stand-alone Elasticsearch node on > my laptop, and am using the transport client to connect to it. When I > initialize the client using "sniff=true", and then print out the list of > connected nodes, as follows: > > ``` > TransportClient client = new TransportClient( > ImmutableSettings.builder() > .put("client.transport.ignore_cluster_name",true) > .put("client.transport.sniff",true) > ); > > client.addTransportAddress(new > > ``` > > InetSocketTransportAddress("192.168.1.5",9300)); > > ``` > for(DiscoveryNode node: client.connectedNodes()) { > System.out.println(node); > } > > ``` > > I get two nodes in the output: > > [#transport#-1][Stefans-MacBook-Pro.local][inet[/192.168.1.5:9300]] > [Diablo][15AyTluTS4Wj26tKgkyQDA][Stefans-MacBook-Pro.local][inet[/ > 192.168.1.5:9300]] > > These are the same node listed twice, presumably once as the node that I > added via "addTransportAddress()", and once as sniffed out by the sniffer. > You can tell that the latter one is more detailed, and includes the actual > node id and name, while the former is just the basic network information. > Notice also that they both refer to the same IP and port combination. > > When I run the same test, but with sniff=false, I get one node, but > somewhat surprisingly, the generic "transport" node has been dropped from > the list: > > [Diablo][15AyTluTS4Wj26tKgkyQDA][Stefans-MacBook-Pro.local][inet[/ > 192.168.1.5:9300]] > > I this the expected behavior ? Why does the sniffer not simply _replace_ > the node info like the client does with sniff=false ? Why does it > essentially leave the node in there twice, apparently ignoring the fact > that there are two entries with the exact same connection info ? > > I looked at the code, and apparently it dedupes nodes based on ID, which > in this case are obviously different (#transport#-1 > vs 15AyTluTS4Wj26tKgkyQDA), but ignores the fact that the IP and port are > identical. > > My expectation was that with sniff=true, it would replace the initial with > the one sniffed from the cluster, and then add any additional nodes it has > discovered, but in reality, I end up with 2x the nodes when I add my entire > cluster via addTransportAddress(). > > Thanks, > > Stefan > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com) > [https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com?utm_medium=email&utm_source=footer) > . > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHNGv6mqLLRm8z4QfFqqoi1New0OP0oGiM%3D9QbZOX\_%2B1g%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHNGv6mqLLRm8z4QfFqqoi1New0OP0oGiM%3D9QbZOX_%2B1g%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Stefan\_Will](https://avatars.discourse-cdn.com/v4/letter/s/9dc877/32.png) [@Stefan\_Will](https://discuss.elastic.co/u/Stefan_Will)\ **Post date:** [September 2, 2014, 6:31pm UTC](https://discuss.elastic.co/t/transport-client-connectednodes-duplicates/19564/4 "2014-09-02T18:31:34Z")
Interesting… for what it’s worth, it was indeed binding to the local IPv6 wildcard address, but publishing the external IPv4 address: [2014-09-01 21:14:05,560][INFO][http] [Diablo] bound\_address {inet[/0:0:0:0:0:0:0:0%0:9200]}, publish\_address {inet[/192.168.1.5:9200]} After setting "network.host: _non\_loopback:ipv4_”, it’s now both binding to and publishing the same address: [2014-09-02 14:18:46,988][INFO][http] [Hijacker] bound\_address {inet[/192.168.1.5:9200]}, publish\_address {inet[/192.168.1.5:9200]} But that had no effect on the result, and the node is still duplicated: [#transport#-1][Stefans-MacBook-Pro.local][inet[/192.168.1.5:9300]] [Hijacker][\_KM9\_mF3S96xoUx402c-dQ][Stefans-MacBook-Pro.local][inet[/192.168.1.5:9300]] FWIW, for different reasons I had already disabled IPv6 on my primary interface a while ago (via networksetup -setv6off Wi-Fi). — Stefan On Tue, Sep 2, 2014 at 1:26 PM, [joergprante@gmail.com](mailto:joergprante@gmail.com) [joergprante@gmail.com](mailto:joergprante@gmail.com) wrote: > The two nodes are okay. The #transport# node connection on Mac OS X is just > using IPv6. ES enumerates all network devices so it finds out about that > connection. No need to be concerned, it can be configured if you want that, > either by JVM property, or by elasticsearch settings in config for the > network module. > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-network.html#modules-network) > Jörg > On Tue, Sep 2, 2014 at 4:50 AM, Stefan Will [stefan.will@gmail.com](mailto:stefan.will@gmail.com) wrote: > > > Hi, > > > > for testing purposes, I've started up a stand-alone Elasticsearch node on > > my laptop, and am using the transport client to connect to it. When I > > initialize the client using "sniff=true", and then print out the list of > > connected nodes, as follows: > > > > ``` > > TransportClient client = new TransportClient( > > ImmutableSettings.builder() > > .put("client.transport.ignore_cluster_name",true) > > .put("client.transport.sniff",true) > > ); > > > > client.addTransportAddress(new > > > > ``` > > > > InetSocketTransportAddress("192.168.1.5",9300)); > > > > ``` > > for(DiscoveryNode node: client.connectedNodes()) { > > System.out.println(node); > > } > > > > ``` > > > > I get two nodes in the output: > > > > [#transport#-1][Stefans-MacBook-Pro.local][inet[/192.168.1.5:9300]] > > [Diablo][15AyTluTS4Wj26tKgkyQDA][Stefans-MacBook-Pro.local][inet[/ > > 192.168.1.5:9300]] > > > > These are the same node listed twice, presumably once as the node that I > > added via "addTransportAddress()", and once as sniffed out by the sniffer. > > You can tell that the latter one is more detailed, and includes the actual > > node id and name, while the former is just the basic network information. > > Notice also that they both refer to the same IP and port combination. > > > > When I run the same test, but with sniff=false, I get one node, but > > somewhat surprisingly, the generic "transport" node has been dropped from > > the list: > > > > [Diablo][15AyTluTS4Wj26tKgkyQDA][Stefans-MacBook-Pro.local][inet[/ > > 192.168.1.5:9300]] > > > > I this the expected behavior ? Why does the sniffer not simply _replace_ > > the node info like the client does with sniff=false ? Why does it > > essentially leave the node in there twice, apparently ignoring the fact > > that there are two entries with the exact same connection info ? > > > > I looked at the code, and apparently it dedupes nodes based on ID, which > > in this case are obviously different (#transport#-1 > > vs 15AyTluTS4Wj26tKgkyQDA), but ignores the fact that the IP and port are > > identical. > > > > My expectation was that with sniff=true, it would replace the initial with > > the one sniffed from the cluster, and then add any additional nodes it has > > discovered, but in reality, I end up with 2x the nodes when I add my entire > > cluster via addTransportAddress(). > > > > Thanks, > > > > Stefan > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > -- > You received this message because you are subscribed to a topic in the Google Groups "elasticsearch" group. > To unsubscribe from this topic, visit [https://groups.google.com/d/topic/elasticsearch/7AN6m\_sK7yI/unsubscribe](https://groups.google.com/d/topic/elasticsearch/7AN6m_sK7yI/unsubscribe). > To unsubscribe from this group and all its topics, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHNGv6mqLLRm8z4QfFqqoi1New0OP0oGiM%3D9QbZOX\_%2B1g%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHNGv6mqLLRm8z4QfFqqoi1New0OP0oGiM%3D9QbZOX_%2B1g%40mail.gmail.com). > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/1409682693421.17318b27%40Nodemailer](https://groups.google.com/d/msgid/elasticsearch/1409682693421.17318b27%40Nodemailer). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [September 2, 2014, 7:30pm UTC](https://discuss.elastic.co/t/transport-client-connectednodes-duplicates/19564/5 "2014-09-02T19:30:56Z")
When I start a default ES node on Mac OSX, it opens on address "0" ("bind to all interfaces") a server socket, so I can see this in netstat tcp46 0 0 \*.9300 _._ LISTEN This means a TCP6 port (in hybrid mode with TCP4 stack compatbility) is used. For the JVM, this will be recognized as two interfaces. This can be demonstrated with the ListNets program at > **[Listing Network Interface Addresses (The Java™ Tutorials \> ...](https://docs.oracle.com/javase/tutorial/networking/nifs/listing.html)** > > This networking Java tutorial describes networking capabilities of the Java platform, working with URLs, sockets, datagrams, and cookies It shows something like Display name: en0 Name: en0 InetAddress: /fe80:0:0:0:7a31:c1ff:fed6:f350%en0 InetAddress: /192.168.1.250 Display name: lo0 Name: lo0 InetAddress: /fe80:0:0:0:0:0:0:1%lo0 InetAddress: /0:0:0:0:0:0:0:1 InetAddress: /127.0.0.1 If sniff mode sees this and ES discovery is set to IP multicast (which is the default), it will receive a response from en0 (lo0 is not able to do multicast) and tries to open two connections to the node on "en0", because there are two addresses on that interface. If JVM is set to "java.net.preferIPv4Stack=true", it simply means for ES to open two IPv4 connections to the address. Jörg On Tue, Sep 2, 2014 at 8:31 PM, Stefan Will [stefan.will@gmail.com](mailto:stefan.will@gmail.com) wrote: > Interesting… for what it’s worth, it was indeed binding to the local IPv6 > wildcard address, but publishing the external IPv4 address: > > [2014-09-01 21:14:05,560][INFO][http] [Diablo] > bound\_address {inet[/0:0:0:0:0:0:0:0%0:9200]}, publish\_address {inet[/ > 192.168.1.5:9200]} > > After setting "network.host: _non\_loopback:ipv4_”, it’s now both binding > to and publishing the same address: > > [2014-09-02 14:18:46,988][INFO][http] [Hijacker] > bound\_address {inet[/192.168.1.5:9200]}, publish\_address {inet[/ > 192.168.1.5:9200]} > > But that had no effect on the result, and the node is still duplicated: > > [#transport#-1][Stefans-MacBook-Pro.local][inet[/192.168.1.5:9300]] > [Hijacker][\_KM9\_mF3S96xoUx402c-dQ][Stefans-MacBook-Pro.local][inet[/ > 192.168.1.5:9300]] > > FWIW, for different reasons I had already disabled IPv6 on my primary > interface a while ago (via networksetup -setv6off Wi-Fi). > > — Stefan > > On Tue, Sep 2, 2014 at 1:26 PM, [joergprante@gmail.com](mailto:joergprante@gmail.com) \< > [joergprante@gmail.com](mailto:joergprante@gmail.com)\> wrote: > > > The two nodes are okay. The #transport# node connection on Mac OS X is > > just using IPv6. ES enumerates all network devices so it finds out about > > that connection. No need to be concerned, it can be configured if you want > > that, either by JVM property, or by elasticsearch settings in config for > > the network module. > > > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-network.html#modules-network) > > > > Jörg > > > > On Tue, Sep 2, 2014 at 4:50 AM, Stefan Will [stefan.will@gmail.com](mailto:stefan.will@gmail.com) > > wrote: > > > > > Hi, > > > > > > for testing purposes, I've started up a stand-alone Elasticsearch node > > > on my laptop, and am using the transport client to connect to it. When I > > > initialize the client using "sniff=true", and then print out the list of > > > connected nodes, as follows: > > > > > > ``` > > > TransportClient client = new TransportClient( > > > ImmutableSettings.builder() > > > .put("client.transport.ignore_cluster_name",true) > > > .put("client.transport.sniff",true) > > > ); > > > > > > client.addTransportAddress(new > > > > > > ``` > > > > > > InetSocketTransportAddress("192.168.1.5",9300)); > > > > > > ``` > > > for(DiscoveryNode node: client.connectedNodes()) { > > > System.out.println(node); > > > } > > > > > > ``` > > > > > > I get two nodes in the output: > > > > > > [#transport#-1][Stefans-MacBook-Pro.local][inet[/192.168.1.5:9300]] > > > [Diablo][15AyTluTS4Wj26tKgkyQDA][Stefans-MacBook-Pro.local][inet[/ > > > 192.168.1.5:9300]] > > > > > > These are the same node listed twice, presumably once as the node that I > > > added via "addTransportAddress()", and once as sniffed out by the sniffer. > > > You can tell that the latter one is more detailed, and includes the actual > > > node id and name, while the former is just the basic network information. > > > Notice also that they both refer to the same IP and port combination. > > > > > > When I run the same test, but with sniff=false, I get one node, but > > > somewhat surprisingly, the generic "transport" node has been dropped from > > > the list: > > > > > > [Diablo][15AyTluTS4Wj26tKgkyQDA][Stefans-MacBook-Pro.local][inet[/ > > > 192.168.1.5:9300]] > > > > > > I this the expected behavior ? Why does the sniffer not simply _replace_ > > > the node info like the client does with sniff=false ? Why does it > > > essentially leave the node in there twice, apparently ignoring the fact > > > that there are two entries with the exact same connection info ? > > > > > > I looked at the code, and apparently it dedupes nodes based on ID, which > > > in this case are obviously different (#transport#-1 > > > vs 15AyTluTS4Wj26tKgkyQDA), but ignores the fact that the IP and port are > > > identical. > > > > > > My expectation was that with sniff=true, it would replace the initial > > > with the one sniffed from the cluster, and then add any additional nodes it > > > has discovered, but in reality, I end up with 2x the nodes when I add my > > > entire cluster via addTransportAddress(). > > > > > > Thanks, > > > > > > Stefan > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > > an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > -- > > You received this message because you are subscribed to a topic in the > > Google Groups "elasticsearch" group. > > To unsubscribe from this topic, visit > > [https://groups.google.com/d/topic/elasticsearch/7AN6m\_sK7yI/unsubscribe](https://groups.google.com/d/topic/elasticsearch/7AN6m_sK7yI/unsubscribe). > > To unsubscribe from this group and all its topics, send an email to > > [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHNGv6mqLLRm8z4QfFqqoi1New0OP0oGiM%3D9QbZOX\_%2B1g%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHNGv6mqLLRm8z4QfFqqoi1New0OP0oGiM%3D9QbZOX_%2B1g%40mail.gmail.com) > > [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHNGv6mqLLRm8z4QfFqqoi1New0OP0oGiM%3D9QbZOX\_%2B1g%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHNGv6mqLLRm8z4QfFqqoi1New0OP0oGiM%3D9QbZOX_%2B1g%40mail.gmail.com?utm_medium=email&utm_source=footer) > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/1409682693421.17318b27%40Nodemailer](https://groups.google.com/d/msgid/elasticsearch/1409682693421.17318b27%40Nodemailer) > [https://groups.google.com/d/msgid/elasticsearch/1409682693421.17318b27%40Nodemailer?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/1409682693421.17318b27%40Nodemailer?utm_medium=email&utm_source=footer) > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoH1RH6VNpzT1LUtfqjPnyj%2BvNQYD%3DSjfOTETc\_E-hP\_mw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoH1RH6VNpzT1LUtfqjPnyj%2BvNQYD%3DSjfOTETc_E-hP_mw%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Stefan\_Will](https://avatars.discourse-cdn.com/v4/letter/s/9dc877/32.png) [@Stefan\_Will](https://discuss.elastic.co/u/Stefan_Will)\ **Post date:** [September 2, 2014, 8:23pm UTC](https://discuss.elastic.co/t/transport-client-connectednodes-duplicates/19564/6 "2014-09-02T20:23:14Z")
But I’m using unicast… ("discovery.zen.ping.multicast: false”), on both the server, and the client. Also, after setting "network.host: _non\_loopback:ipv4_”, the ES node is no longer binding to the wildcard (0), but directly to my local LAN address. I can confirm using netstat: tcp4 0 0 192.168.1.5.9300 _._ LISTEN Since I disabled IPv6, /en0 only has a single IPv4 address on my machine (based on ListNets): Display name: en0 Name: en0 InetAddress: /192.168.1.5 Even with all this, the transport (not node) client still gives me a duplicate node. The same behavior happens on Ubuntu as well by the way. — Stefan BTW - here’s the configuration of my ES server: cluster.name: development discovery.zen.ping.multicast: false network.host: _non\_loopback:ipv4_ index.number\_of\_shards: 3 index.number\_of\_replicas: 0 script.disable\_dynamic: true and this is how I initialized my client: ``` TransportClient client = new TransportClient( ImmutableSettings.builder() .put("client.transport.ignore_cluster_name",true) .put("client.transport.sniff",true) .put("discovery.zen.ping.multicast",false) ); ``` On Tue, Sep 2, 2014 at 3:31 PM, [joergprante@gmail.com](mailto:joergprante@gmail.com) [joergprante@gmail.com](mailto:joergprante@gmail.com) wrote: > When I start a default ES node on Mac OSX, it opens on address "0" ("bind > to all interfaces") a server socket, so I can see this in netstat > tcp46 0 0 \*.9300 _._ LISTEN > This means a TCP6 port (in hybrid mode with TCP4 stack compatbility) is > used. For the JVM, this will be recognized as two interfaces. > This can be demonstrated with the ListNets program at > [Listing Network Interface Addresses (The Java™ Tutorials \> Custom Networking \> Programmatic Access to Network Parameters)](http://docs.oracle.com/javase/tutorial/networking/nifs/listing.html) > It shows something like > Display name: en0 > Name: en0 > InetAddress: /fe80:0:0:0:7a31:c1ff:fed6:f350%en0 > InetAddress: /192.168.1.250 > Display name: lo0 > Name: lo0 > InetAddress: /fe80:0:0:0:0:0:0:1%lo0 > InetAddress: /0:0:0:0:0:0:0:1 > InetAddress: /127.0.0.1 > If sniff mode sees this and ES discovery is set to IP multicast (which is > the default), it will receive a response from en0 (lo0 is not able to do > multicast) and tries to open two connections to the node on "en0", because > there are two addresses on that interface. If JVM is set to > "java.net.preferIPv4Stack=true", it simply means for ES to open two IPv4 > connections to the address. > Jörg > On Tue, Sep 2, 2014 at 8:31 PM, Stefan Will [stefan.will@gmail.com](mailto:stefan.will@gmail.com) wrote: > > > Interesting… for what it’s worth, it was indeed binding to the local IPv6 > > wildcard address, but publishing the external IPv4 address: > > > > [2014-09-01 21:14:05,560][INFO][http] [Diablo] > > bound\_address {inet[/0:0:0:0:0:0:0:0%0:9200]}, publish\_address {inet[/ > > 192.168.1.5:9200]} > > > > After setting "network.host: _non\_loopback:ipv4_”, it’s now both binding > > to and publishing the same address: > > > > [2014-09-02 14:18:46,988][INFO][http] [Hijacker] > > bound\_address {inet[/192.168.1.5:9200]}, publish\_address {inet[/ > > 192.168.1.5:9200]} > > > > But that had no effect on the result, and the node is still duplicated: > > > > [#transport#-1][Stefans-MacBook-Pro.local][inet[/192.168.1.5:9300]] > > [Hijacker][\_KM9\_mF3S96xoUx402c-dQ][Stefans-MacBook-Pro.local][inet[/ > > 192.168.1.5:9300]] > > > > FWIW, for different reasons I had already disabled IPv6 on my primary > > interface a while ago (via networksetup -setv6off Wi-Fi). > > > > — Stefan > > > > On Tue, Sep 2, 2014 at 1:26 PM, [joergprante@gmail.com](mailto:joergprante@gmail.com) \< > > [joergprante@gmail.com](mailto:joergprante@gmail.com)\> wrote: > > > > > The two nodes are okay. The #transport# node connection on Mac OS X is > > > just using IPv6. ES enumerates all network devices so it finds out about > > > that connection. No need to be concerned, it can be configured if you want > > > that, either by JVM property, or by elasticsearch settings in config for > > > the network module. > > > > > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-network.html#modules-network) > > > > > > Jörg > > > > > > On Tue, Sep 2, 2014 at 4:50 AM, Stefan Will [stefan.will@gmail.com](mailto:stefan.will@gmail.com) > > > wrote: > > > > > > > Hi, > > > > > > > > for testing purposes, I've started up a stand-alone Elasticsearch node > > > > on my laptop, and am using the transport client to connect to it. When I > > > > initialize the client using "sniff=true", and then print out the list of > > > > connected nodes, as follows: > > > > > > > > ``` > > > > TransportClient client = new TransportClient( > > > > ImmutableSettings.builder() > > > > .put("client.transport.ignore_cluster_name",true) > > > > .put("client.transport.sniff",true) > > > > ); > > > > > > > > client.addTransportAddress(new > > > > > > > > ``` > > > > > > > > InetSocketTransportAddress("192.168.1.5",9300)); > > > > > > > > ``` > > > > for(DiscoveryNode node: client.connectedNodes()) { > > > > System.out.println(node); > > > > } > > > > > > > > ``` > > > > > > > > I get two nodes in the output: > > > > > > > > [#transport#-1][Stefans-MacBook-Pro.local][inet[/192.168.1.5:9300]] > > > > [Diablo][15AyTluTS4Wj26tKgkyQDA][Stefans-MacBook-Pro.local][inet[/ > > > > 192.168.1.5:9300]] > > > > > > > > These are the same node listed twice, presumably once as the node that I > > > > added via "addTransportAddress()", and once as sniffed out by the sniffer. > > > > You can tell that the latter one is more detailed, and includes the actual > > > > node id and name, while the former is just the basic network information. > > > > Notice also that they both refer to the same IP and port combination. > > > > > > > > When I run the same test, but with sniff=false, I get one node, but > > > > somewhat surprisingly, the generic "transport" node has been dropped from > > > > the list: > > > > > > > > [Diablo][15AyTluTS4Wj26tKgkyQDA][Stefans-MacBook-Pro.local][inet[/ > > > > 192.168.1.5:9300]] > > > > > > > > I this the expected behavior ? Why does the sniffer not simply _replace_ > > > > the node info like the client does with sniff=false ? Why does it > > > > essentially leave the node in there twice, apparently ignoring the fact > > > > that there are two entries with the exact same connection info ? > > > > > > > > I looked at the code, and apparently it dedupes nodes based on ID, which > > > > in this case are obviously different (#transport#-1 > > > > vs 15AyTluTS4Wj26tKgkyQDA), but ignores the fact that the IP and port are > > > > identical. > > > > > > > > My expectation was that with sniff=true, it would replace the initial > > > > with the one sniffed from the cluster, and then add any additional nodes it > > > > has discovered, but in reality, I end up with 2x the nodes when I add my > > > > entire cluster via addTransportAddress(). > > > > > > > > Thanks, > > > > > > > > Stefan > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "elasticsearch" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > > > To view this discussion on the web visit > > > > [https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com) > > > > [https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > -- > > > You received this message because you are subscribed to a topic in the > > > Google Groups "elasticsearch" group. > > > To unsubscribe from this topic, visit > > > [https://groups.google.com/d/topic/elasticsearch/7AN6m\_sK7yI/unsubscribe](https://groups.google.com/d/topic/elasticsearch/7AN6m_sK7yI/unsubscribe). > > > To unsubscribe from this group and all its topics, send an email to > > > [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHNGv6mqLLRm8z4QfFqqoi1New0OP0oGiM%3D9QbZOX\_%2B1g%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHNGv6mqLLRm8z4QfFqqoi1New0OP0oGiM%3D9QbZOX_%2B1g%40mail.gmail.com) > > > [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHNGv6mqLLRm8z4QfFqqoi1New0OP0oGiM%3D9QbZOX\_%2B1g%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHNGv6mqLLRm8z4QfFqqoi1New0OP0oGiM%3D9QbZOX_%2B1g%40mail.gmail.com?utm_medium=email&utm_source=footer) > > > . > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/1409682693421.17318b27%40Nodemailer](https://groups.google.com/d/msgid/elasticsearch/1409682693421.17318b27%40Nodemailer) > > [https://groups.google.com/d/msgid/elasticsearch/1409682693421.17318b27%40Nodemailer?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/1409682693421.17318b27%40Nodemailer?utm_medium=email&utm_source=footer) > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > -- > You received this message because you are subscribed to a topic in the Google Groups "elasticsearch" group. > To unsubscribe from this topic, visit [https://groups.google.com/d/topic/elasticsearch/7AN6m\_sK7yI/unsubscribe](https://groups.google.com/d/topic/elasticsearch/7AN6m_sK7yI/unsubscribe). > To unsubscribe from this group and all its topics, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoH1RH6VNpzT1LUtfqjPnyj%2BvNQYD%3DSjfOTETc\_E-hP\_mw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoH1RH6VNpzT1LUtfqjPnyj%2BvNQYD%3DSjfOTETc_E-hP_mw%40mail.gmail.com). > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/1409689393290.7d4059fe%40Nodemailer](https://groups.google.com/d/msgid/elasticsearch/1409689393290.7d4059fe%40Nodemailer). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [September 2, 2014, 9:05pm UTC](https://discuss.elastic.co/t/transport-client-connectednodes-duplicates/19564/7 "2014-09-02T21:05:48Z")
Hmmmm that's weird, never was aware of that... I always thought it was a hybrid tcp46 port issue. Will check if it is the same on my linux machines. Jörg On Tue, Sep 2, 2014 at 10:23 PM, Stefan Will [stefan.will@gmail.com](mailto:stefan.will@gmail.com) wrote: > But I’m using unicast… ("discovery.zen.ping.multicast: false”), on both > the server, and the client. Also, after setting "network.host: > _non\_loopback:ipv4_”, the ES node is no longer binding to the wildcard (0), > but directly to my local LAN address. I can confirm using netstat: > > tcp4 0 0 192.168.1.5.9300 _._ > LISTEN > > Since I disabled IPv6, /en0 only has a single IPv4 address on my machine > (based on ListNets): > > Display name: en0 > Name: en0 > InetAddress: /192.168.1.5 > > Even with all this, the transport (not node) client still gives me a > duplicate node. The same behavior happens on Ubuntu as well by the way. > > — Stefan > > BTW - here’s the configuration of my ES server: > > cluster.name: development > discovery.zen.ping.multicast: false > network.host: _non\_loopback:ipv4_ > index.number\_of\_shards: 3 > index.number\_of\_replicas: 0 > script.disable\_dynamic: true > > and this is how I initialized my client: > > ``` > TransportClient client = new TransportClient( > ImmutableSettings.builder() > .put("client.transport.ignore_cluster_name",true) > .put("client.transport.sniff",true) > .put("discovery.zen.ping.multicast",false) > ); > > ``` > > On Tue, Sep 2, 2014 at 3:31 PM, [joergprante@gmail.com](mailto:joergprante@gmail.com) \< > [joergprante@gmail.com](mailto:joergprante@gmail.com)\> wrote: > > > When I start a default ES node on Mac OSX, it opens on address "0" > > ("bind to all interfaces") a server socket, so I can see this in netstat > > > > tcp46 0 0 \*.9300 _._ LISTEN > > > > This means a TCP6 port (in hybrid mode with TCP4 stack compatbility) is > > used. For the JVM, this will be recognized as two interfaces. > > > > This can be demonstrated with the ListNets program at > > [Listing Network Interface Addresses (The Java™ Tutorials \> Custom Networking \> Programmatic Access to Network Parameters)](http://docs.oracle.com/javase/tutorial/networking/nifs/listing.html) > > > > It shows something like > > > > Display name: en0 > > Name: en0 > > InetAddress: /fe80:0:0:0:7a31:c1ff:fed6:f350%en0 > > InetAddress: /192.168.1.250 > > > > Display name: lo0 > > Name: lo0 > > InetAddress: /fe80:0:0:0:0:0:0:1%lo0 > > InetAddress: /0:0:0:0:0:0:0:1 > > InetAddress: /127.0.0.1 > > > > If sniff mode sees this and ES discovery is set to IP multicast (which is > > the default), it will receive a response from en0 (lo0 is not able to do > > multicast) and tries to open two connections to the node on "en0", because > > there are two addresses on that interface. If JVM is set to > > "java.net.preferIPv4Stack=true", it simply means for ES to open two IPv4 > > connections to the address. > > > > Jörg > > > > On Tue, Sep 2, 2014 at 8:31 PM, Stefan Will [stefan.will@gmail.com](mailto:stefan.will@gmail.com) > > wrote: > > > > > Interesting… for what it’s worth, it was indeed binding to the local > > > IPv6 wildcard address, but publishing the external IPv4 address: > > > > > > [2014-09-01 21:14:05,560][INFO][http] [Diablo] > > > bound\_address {inet[/0:0:0:0:0:0:0:0%0:9200]}, publish\_address {inet[/ > > > 192.168.1.5:9200]} > > > > > > After setting "network.host: _non\_loopback:ipv4_”, it’s now both binding > > > to and publishing the same address: > > > > > > [2014-09-02 14:18:46,988][INFO][http] [Hijacker] > > > bound\_address {inet[/192.168.1.5:9200]}, publish\_address {inet[/ > > > 192.168.1.5:9200]} > > > > > > But that had no effect on the result, and the node is still duplicated: > > > > > > [#transport#-1][Stefans-MacBook-Pro.local][inet[/192.168.1.5:9300]] > > > [Hijacker][\_KM9\_mF3S96xoUx402c-dQ][Stefans-MacBook-Pro.local][inet[/ > > > 192.168.1.5:9300]] > > > > > > FWIW, for different reasons I had already disabled IPv6 on my primary > > > interface a while ago (via networksetup -setv6off Wi-Fi). > > > > > > — Stefan > > > > > > On Tue, Sep 2, 2014 at 1:26 PM, [joergprante@gmail.com](mailto:joergprante@gmail.com) \< > > > [joergprante@gmail.com](mailto:joergprante@gmail.com)\> wrote: > > > > > > > The two nodes are okay. The #transport# node connection on Mac OS X > > > > is just using IPv6. ES enumerates all network devices so it finds out about > > > > that connection. No need to be concerned, it can be configured if you want > > > > that, either by JVM property, or by elasticsearch settings in config for > > > > the network module. > > > > > > > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-network.html#modules-network) > > > > > > > > Jörg > > > > > > > > On Tue, Sep 2, 2014 at 4:50 AM, Stefan Will [stefan.will@gmail.com](mailto:stefan.will@gmail.com) > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > for testing purposes, I've started up a stand-alone Elasticsearch node > > > > > on my laptop, and am using the transport client to connect to it. When I > > > > > initialize the client using "sniff=true", and then print out the list of > > > > > connected nodes, as follows: > > > > > > > > > > ``` > > > > > TransportClient client = new TransportClient( > > > > > ImmutableSettings.builder() > > > > > .put("client.transport.ignore_cluster_name",true) > > > > > .put("client.transport.sniff",true) > > > > > ); > > > > > > > > > > client.addTransportAddress(new > > > > > > > > > > ``` > > > > > > > > > > InetSocketTransportAddress("192.168.1.5",9300)); > > > > > > > > > > ``` > > > > > for(DiscoveryNode node: client.connectedNodes()) { > > > > > System.out.println(node); > > > > > } > > > > > > > > > > ``` > > > > > > > > > > I get two nodes in the output: > > > > > > > > > > [#transport#-1][Stefans-MacBook-Pro.local][inet[/192.168.1.5:9300]] > > > > > [Diablo][15AyTluTS4Wj26tKgkyQDA][Stefans-MacBook-Pro.local][inet[/ > > > > > 192.168.1.5:9300]] > > > > > > > > > > These are the same node listed twice, presumably once as the node that > > > > > I added via "addTransportAddress()", and once as sniffed out by the > > > > > sniffer. You can tell that the latter one is more detailed, and includes > > > > > the actual node id and name, while the former is just the basic network > > > > > information. Notice also that they both refer to the same IP and port > > > > > combination. > > > > > > > > > > When I run the same test, but with sniff=false, I get one node, but > > > > > somewhat surprisingly, the generic "transport" node has been dropped from > > > > > the list: > > > > > > > > > > [Diablo][15AyTluTS4Wj26tKgkyQDA][Stefans-MacBook-Pro.local][inet[/ > > > > > 192.168.1.5:9300]] > > > > > > > > > > I this the expected behavior ? Why does the sniffer not simply > > > > > _replace_ the node info like the client does with sniff=false ? Why does it > > > > > essentially leave the node in there twice, apparently ignoring the fact > > > > > that there are two entries with the exact same connection info ? > > > > > > > > > > I looked at the code, and apparently it dedupes nodes based on ID, > > > > > which in this case are obviously different (#transport#-1 > > > > > vs 15AyTluTS4Wj26tKgkyQDA), but ignores the fact that the IP and port are > > > > > identical. > > > > > > > > > > My expectation was that with sniff=true, it would replace the initial > > > > > with the one sniffed from the cluster, and then add any additional nodes it > > > > > has discovered, but in reality, I end up with 2x the nodes when I add my > > > > > entire cluster via addTransportAddress(). > > > > > > > > > > Thanks, > > > > > > > > > > Stefan > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups "elasticsearch" group. > > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > > an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > > > > To view this discussion on the web visit > > > > > [https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com) > > > > > [https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/0f7ca562-8a91-469f-98d3-08e8a27d4ea1%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > . > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > -- > > > > You received this message because you are subscribed to a topic in the > > > > Google Groups "elasticsearch" group. > > > > To unsubscribe from this topic, visit > > > > [https://groups.google.com/d/topic/elasticsearch/7AN6m\_sK7yI/unsubscribe](https://groups.google.com/d/topic/elasticsearch/7AN6m_sK7yI/unsubscribe) > > > > . > > > > To unsubscribe from this group and all its topics, send an email to > > > > [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > > > To view this discussion on the web visit > > > > [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHNGv6mqLLRm8z4QfFqqoi1New0OP0oGiM%3D9QbZOX\_%2B1g%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHNGv6mqLLRm8z4QfFqqoi1New0OP0oGiM%3D9QbZOX_%2B1g%40mail.gmail.com) > > > > [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHNGv6mqLLRm8z4QfFqqoi1New0OP0oGiM%3D9QbZOX\_%2B1g%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHNGv6mqLLRm8z4QfFqqoi1New0OP0oGiM%3D9QbZOX_%2B1g%40mail.gmail.com?utm_medium=email&utm_source=footer) > > > > . > > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > > an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/1409682693421.17318b27%40Nodemailer](https://groups.google.com/d/msgid/elasticsearch/1409682693421.17318b27%40Nodemailer) > > > [https://groups.google.com/d/msgid/elasticsearch/1409682693421.17318b27%40Nodemailer?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/1409682693421.17318b27%40Nodemailer?utm_medium=email&utm_source=footer) > > > . > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > -- > > You received this message because you are subscribed to a topic in the > > Google Groups "elasticsearch" group. > > To unsubscribe from this topic, visit > > [https://groups.google.com/d/topic/elasticsearch/7AN6m\_sK7yI/unsubscribe](https://groups.google.com/d/topic/elasticsearch/7AN6m_sK7yI/unsubscribe). > > To unsubscribe from this group and all its topics, send an email to > > [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoH1RH6VNpzT1LUtfqjPnyj%2BvNQYD%3DSjfOTETc\_E-hP\_mw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoH1RH6VNpzT1LUtfqjPnyj%2BvNQYD%3DSjfOTETc_E-hP_mw%40mail.gmail.com) > > [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoH1RH6VNpzT1LUtfqjPnyj%2BvNQYD%3DSjfOTETc\_E-hP\_mw%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoH1RH6VNpzT1LUtfqjPnyj%2BvNQYD%3DSjfOTETc_E-hP_mw%40mail.gmail.com?utm_medium=email&utm_source=footer) > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/1409689393290.7d4059fe%40Nodemailer](https://groups.google.com/d/msgid/elasticsearch/1409689393290.7d4059fe%40Nodemailer) > [https://groups.google.com/d/msgid/elasticsearch/1409689393290.7d4059fe%40Nodemailer?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/1409689393290.7d4059fe%40Nodemailer?utm_medium=email&utm_source=footer) > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFM6Lb75Y%3DZZo8aRmjx78CMJHPR04xEpTUKEKOoYQ7V6Q%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFM6Lb75Y%3DZZo8aRmjx78CMJHPR04xEpTUKEKOoYQ7V6Q%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**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, 1:04am UTC](https://discuss.elastic.co/t/transport-client-connectednodes-duplicates/19564/8 "2017-07-06T01:04:52Z")