使用弹性云/查找从主节点NoNodeAvailableException随机断开连接

Question

我使用弹性云(前发现)与屏蔽和传输java客户端。与ES通信的应用程序运行在heroku上。我正在一个节点的准备环境上运行一个压力测试

{
    "cluster_name": ...,
    "status": "yellow", 
    "timed_out": false,
    "number_of_nodes": 1,
    "number_of_data_nodes": 1,
    "active_primary_shards": 19,
    "active_shards": 19,
    "relocating_shards": 0,
    "initializing_shards": 0,
    "unassigned_shards": 7,
    "delayed_unassigned_shards": 0,
    "number_of_pending_tasks": 0,
    "number_of_in_flight_fetch": 0
}

A开头一切都很完美。但过了一段时间(3-4分钟)，我开始犯一些错误.我已经将日志级别设置为跟踪，这些都是我所遇到的错误(我已经用...替换了所有无关的内容。

org.elasticsearch.client.transport.NoNodeAvailableException: None of the configured nodes were available: [[...][...][...][inet[...]]{logical_availability_zone=..., availability_zone=..., max_local_storage_nodes=1, region=..., master=true}]
    at org.elasticsearch.client.transport.TransportClientNodesService$RetryListener.onFailure(TransportClientNodesService.java:242)
    at org.elasticsearch.action.TransportActionNodeProxy$1.handleException(TransportActionNodeProxy.java:78)
    at org.elasticsearch.transport.TransportService$3.run(TransportService.java:290)
    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:745)
Caused by: org.elasticsearch.transport.SendRequestTransportException: [...][inet[...]][indices:data/read/search]
    at org.elasticsearch.transport.TransportService.sendRequest(TransportService.java:286)
    at org.elasticsearch.shield.transport.ShieldClientTransportService.sendRequest(ShieldClientTransportService.java:41)
    at org.elasticsearch.action.TransportActionNodeProxy.execute(TransportActionNodeProxy.java:57)
    at org.elasticsearch.client.transport.support.InternalTransportClient$1.doWithNode(InternalTransportClient.java:109)
    at org.elasticsearch.client.transport.TransportClientNodesService.execute(TransportClientNodesService.java:205)
    at org.elasticsearch.client.transport.support.InternalTransportClient.execute(InternalTransportClient.java:106)
    at org.elasticsearch.client.support.AbstractClient.search(AbstractClient.java:334)
    at org.elasticsearch.client.transport.TransportClient.search(TransportClient.java:416)
    at org.elasticsearch.action.search.SearchRequestBuilder.doExecute(SearchRequestBuilder.java:1122)
    at org.elasticsearch.action.ActionRequestBuilder.execute(ActionRequestBuilder.java:91)
    at org.elasticsearch.action.ActionRequestBuilder.execute(ActionRequestBuilder.java:65)
    ...
Caused by: org.elasticsearch.transport.NodeNotConnectedException: [...][inet[...]] Node not connected
    at org.elasticsearch.transport.netty.NettyTransport.nodeChannel(NettyTransport.java:936)
    at org.elasticsearch.transport.netty.NettyTransport.sendRequest(NettyTransport.java:629)
    at org.elasticsearch.transport.TransportService.sendRequest(TransportService.java:276)
    ... 

这些是我的财产

  settings = ImmutableSettings.settingsBuilder()
      .put("client.transport.nodes_sampler_interval", "5s") //Tried it with 30s, same outcome
      .put("client.transport.ping_timeout", "30s")
      .put("cluster.name", clusterName)
      .put("action.bulk.compress", false)
      .put("shield.transport.ssl", true)
      .put("request.headers.X-Found-Cluster", clusterName)
      .put("shield.user", user + ":" + password)
      .put("transport.ping_schedule", "1s") //Tried with 5s, same outcome
      .build();

我还为我所做的每一个查询设置了如下内容：

max_query_response_size=100000
timeout_seconds=30

我使用ElasticSearch 1.7.2和Shield 1.3.2与相应的(相同版本)客户端，在我的机器上使用Java 1.8.0_65 -节点上的Java 1.8.0_40。

在没有压力测试的情况下，我得到了同样的错误，但是这些错误是随机发生的，所以我想要重现。这就是为什么我在一个节点上运行这个程序的原因。

我在日志中发现了另一个错误

2016-03-07 23:35:52,177 DEBUG [elasticsearch[Vermin][transport_client_worker][T#7]{New I/O worker #16}] ssl.SslHandler (NettyInternalESLogger.java:debug(63)) - Swallowing an exception raised while writing non-app data
java.nio.channels.ClosedChannelException
    at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioWorker.cleanUpWriteBuffer(AbstractNioWorker.java:433)
    at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioWorker.close(AbstractNioWorker.java:373)
    at org.elasticsearch.common.netty.channel.socket.nio.NioWorker.read(NioWorker.java:93)
    at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108)
    at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
    at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
    at org.elasticsearch.common.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
    at org.elasticsearch.common.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
    at org.elasticsearch.common.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

热丝

0.0% (111.6micros out of 500ms) cpu usage by thread 'elasticsearch[...][transport_client_timer][T#1]{Hashed wheel timer #1}'
 10/10 snapshots sharing following 5 elements
   java.lang.Thread.sleep(Native Method)
   org.elasticsearch.common.netty.util.HashedWheelTimer$Worker.waitForNextTick(HashedWheelTimer.java:445)
   org.elasticsearch.common.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:364)
   org.elasticsearch.common.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
   java.lang.Thread.run(Thread.java:745)

在阅读了这个http://blog.trifork.com/2015/04/08/dealing-with-nodenotavailableexceptions-in-elasticsearch/之后，我开始更好地理解整个交流是如何运作的。我还没有测试过这个，但我相信问题就在这里。但问题是，即使我确认问题是关闭的查询连接，我如何处理这个问题呢？保持配置的原样，然后重新连接？我是否禁用了keepAlive？如果是的话，我还应该担心别的什么吗？

Answer 1

引用此链接：https://discuss.elastic.co/t/nonodeavailableexception-with-java-transport-client/37702 by 康拉德·贝斯克

您的应用程序可能在启动时解析ip地址。ELB可以在任何时候改变ip。为了获得最佳的可靠性，您的应用程序应该将ELB的所有ip添加到客户端，并定期检查DNS服务的更改。 我们的ELB的连接超时时间是5分钟。

以下是帮助您解决问题的方法：

为每个请求创建一个新的TransportClient并不理想，因为它将意味着对每个请求进行新的连接握手，这将损害您的响应时间。如果您愿意，您可以拥有一个TransportClients池，但这很可能是不必要的开销，因为客户端是线程安全的。 我的建议是创建一个小型的单例服务，定期检查DNS服务的更改，并将任何新ip添加到现有的传输客户端。从理论上讲，这可能会像每次检查时添加所有发现的ip一样天真，因为传输客户端将丢弃重复地址，并清除已无法访问的旧地址。