Java 使用Elastic Cloud/Found从主节点随机断开NoNodeAvailableException

我正在使用ElasticCloud（以前发现的）和shield以及transport 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
}

一开始一切都很完美。但过了一段时间（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

与相应的（相同版本）客户端，

Java1.8.0\u65

在我的机器上-

Java1.8.0\u40

在节点上

我在没有压力测试的情况下得到了相同的错误，但是错误发生的非常随机，所以我想重现。这就是为什么我在单个节点上运行这个

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

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)

读了这篇文章后，我对整个通信的工作原理有了更好的了解。我还没有测试过这一点，但我相信问题就在那里。问题是，即使我确认问题是关闭的查询连接，我该如何处理？保持配置不变，然后重新连接？我是否禁用

keepAlive

？如果是，我应该担心其他事情吗？

引用此链接： 借

您的应用程序可能在启动时解析ip地址 ELB可以在任何时间点更改ip。以获得最佳可靠性 应用程序应将ELB的所有ip添加到客户端和 定期检查DNS服务的更改

我们的ELB的连接超时为5分钟

以下内容可以帮助您修复此问题：

为每个请求创建一个新的TransportClient并不理想，因为 将意味着对每个请求进行新的连接握手，这将 影响您的响应时间。如果 您更愿意，但这很可能是不必要的开销，因为 客户端是线程安全的

我的建议是创建一个小的单例服务 定期检查DNS服务的更改并添加任何新的 将ip连接到现有的传输客户端。理论上，这可能同样幼稚 就像每次检查时添加发现的所有ip一样 传输客户端将丢弃重复的地址，并清除旧地址 无法再访问地址

---

您的压力测试是做什么的？另外，您是否有一个完整的日志文件，从您发生错误并执行压力测试的那一天开始？@andrestefan它保存、删除和大部分搜索。绝大多数调用都是搜索，一些大容量保存，一些大容量和单次删除。完整的日志包含敏感数据，我不在libe中我想这个链接应该能回答你的问题。：）在过去的几天里，我看到了无数次，但我都没有看到。因此，基本上，即使使用find/shield，我也必须轮询IP。这似乎没有被记录下来，因为每个人都使用RESTAPI。请提供一个答案，这样我就可以接受它并奖励奖金。出于某种原因，我必须等待23个小时才能奖励奖金。顺便说一句，我把它翻了一倍。这很难找到，因为即使找到的支持也声称这是由客户自动处理的。感觉不应该，但没有抱怨：）谢谢。很高兴我能帮忙