elasticsearch,action,sharding,Error Handling,elasticsearch,Action,Sharding" /> elasticsearch,action,sharding,Error Handling,elasticsearch,Action,Sharding" />
Fatal编程技术网
  • error-handling/
  • Error handling 失败（和不活动）的碎片是否应该失败整个操作？如何失败？

Error handling 失败（和不活动）的碎片是否应该失败整个操作？如何失败？

error-handling

Error handling 失败（和不活动）的碎片是否应该失败整个操作？如何失败？,error-handling,elasticsearch,action,sharding,Error Handling,elasticsearch,Action,Sharding,我正在开发一个Elasticsearch插件，可以从匹配模式的字段中提取术语。为了完成所有的搭建，我从这个插件开始：。因此，我扩展了TransportBroadcastOperationAction，让它将请求广播到activePrimaryShardsGrouped，然后在newResponse中，合并碎片结果，计算失败的碎片，并最终将计数器传递给BroadcastOperationResponse构造函数 我在ES客户机上称之为： TermListResponse resp = TermLi

我正在开发一个Elasticsearch插件，可以从匹配模式的字段中提取术语。为了完成所有的搭建，我从这个插件开始：。因此，我扩展了
TransportBroadcastOperationAction
，让它将请求广播到
activePrimaryShardsGrouped
，然后在
newResponse
中，合并碎片结果，计算失败的碎片，并最终将计数器传递给
BroadcastOperationResponse
构造函数

我在ES客户机上称之为：

TermListResponse resp = TermListAction.INSTANCE.newRequestBuilder(client)
        .setIndices("foo")
        .setFields("bar", "baaz").setPattern("wombat*")
        .execute().actionGet();
我的问题是，当存在失败的碎片时，上面的不会抛出异常，尽管它表明在
resp.getFailedShards（）
中。应该是这样，还是我做错了什么？在所有调用之后检查
resp.getFailedShards（）
看起来不是很安全，因为有些人可能会忘记这样做，而意外地使用部分术语列表

此外，在我的例子中，碎片失败的原因是集群最近重新启动，因此客户端已经可以连接了，但是一些碎片还没有准备好。我认为，如果操作只是等待广播目标碎片准备就绪（当然会有一些超时），这会很好，很明显，就像搜索请求一样。也许这意味着等待“黄色”集群健康状态，但如果我想忠实于ES的方法，我应该在哪里这样做呢