It sounds like because that isn't a local interface that ES is bound to it tries to access it. Are you using NAT on a higher layer?
On 6 January 2015 at 01:59, Matt Hughes <[email protected]> wrote: > In my VM environment, a VM can't actually see its public IP address. I > have the following setup: > > network.publish_host: 10.255.207.123 > discovery.zen.ping.unicast.hosts: 10.255.207.123,10.255.207.124,10.255. > 207.125 > > > > My VM can see 124 and 125 just fine, but due to issues completely > unrelated to ES, it cannot see its own public IP. As a result, the logs on > each machine fill up with these exceptions: > > org.elasticsearch.transport.ConnectTransportException: [elk2][inet[/ > 10.255.207.123:9300]] connect_timeout[30s] > at > org.elasticsearch.transport.netty.NettyTransport.connectToChannels(NettyTransport.java:807) > at > org.elasticsearch.transport.netty.NettyTransport.connectToNode(NettyTransport.java:741) > at > org.elasticsearch.transport.netty.NettyTransport.connectToNode(NettyTransport.java:714) > at > org.elasticsearch.transport.TransportService.connectToNode(TransportService.java:150) > at > org.elasticsearch.cluster.service.InternalClusterService$ReconnectToNodes.run(InternalClusterService.java:521) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > Caused by: org.elasticsearch.common.netty.channel.ConnectTimeoutException: > connection timed out: /10.255.207.123:9300 > at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss. > processConnectTimeout(NioClientBoss.java:139) > at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss. > process(NioClientBoss.java:83) > at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioSelector > .run(AbstractNioSelector.java:318) > at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.run( > NioClientBoss.java:42) > at org.elasticsearch.common.netty.util.ThreadRenamingRunnable.run( > ThreadRenamingRunnable.java:108) > at org.elasticsearch.common.netty.util.internal.DeadLockProofWorker$1. > run(DeadLockProofWorker.java:42) > > > > I believe this is pretty innocuous as I've been running this way for 6 > months, but I've always been curious as to way my node is even *trying* to > connect to itself like this? As it goes through the list of > 'discovery.zen.ping.unicast.hosts', shouldn't it ignore itself? Maybe ES > doesn't use 'network.publish_host' to determine if the IP belongs to the > current machine? > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/fa2e66cf-1f96-4c9c-8b69-bd146f868ec7%40googlegroups.com > <https://groups.google.com/d/msgid/elasticsearch/fa2e66cf-1f96-4c9c-8b69-bd146f868ec7%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAEYi1X-4Zk90wSrM8Z6oqHR1LGNdLLSB4vcYVqdPp%2BvLWoRMgA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
