Java Cassandra NoHostAvailableException，但仍有活动节点

我在一个DC中有两个C*2.0.2节点（默认配置为cassandra.yaml）和一个RF=2的键空间。两个客户端通过Datastax Java驱动程序1.0.3连接到此DC。客户机从C*读取和写入数据，CL=1，无任何错误。 但当我关闭一个节点时，两个客户端都会出现大量异常：

com.datastax.driver.core.exceptions.NoHostAvailableException:
All host(s) tried for query failed (no host was tried)

在这一系列异常之后，客户机继续与另一个仍然处于活动状态的节点成功协作。我应该怎么做才能不接收任何NoHostAvailableException，因为一次至少有一个活动节点，并且使用了CL=1

更新： 当我关闭两个节点中的一个时，有时会在我的应用程序日志中看到以下异常：

[Reconnection-1] [ERROR] [Control connection] Cannot connect to
any host, scheduling retry

---

如果我只关闭一个节点，为什么两个节点都不可用？第二个节点此时仍处于活动状态，我可以使用cqlsh连接到它。

如果执行CL=1的请求，驱动程序将尝试仅查询单个节点。因此，如果对该节点的请求失败（或该节点不可用），将立即引发异常。此行为由创建

群集时指定的
com.datastax.driver.core.policies.RetryPolicy
控制

我想说的是，一个使重试次数固定的
RetryPolicy
可以满足您的需要。不幸的是，Cassandra Driver 1.0.3没有捆绑（我不确定以后的版本是否捆绑）。尽管如此，它可能是这样实现的：

public class MyRetryPolicy implements RetryPolicy {

    final int attempts;

    public MyRetryPolicy(int attempts) {
        this.attempts = attempts;
    }

    @Override
    public RetryDecision onReadTimeout(Query query, ConsistencyLevel cl, int requiredResponses, int receivedResponses, boolean dataRetrieved, int nbRetry) {
        return (nbRetry >= attempts) ? RetryDecision.rethrow() : RetryDecision.retry(cl)
    }        

    ... <onWriteTimeout & onUnavailable methods with similar implementation>
}

公共类MyRetryPolicy实现RetryPolicy{
最后的尝试；
公共MyRetryPolicy（整数次尝试）{
这个。尝试=尝试；
}
@凌驾
ReadTimeout上的public RetryDecision（查询查询、一致性级别cl、int requiredResponses、int receivedResponses、boolean dataRetrieved、int Nbreatry）{
返回（Nbrery>=尝试）？RetryDecision.rethrow（）：RetryDecision.retry（cl）
}        
... 
}

我不确定MyRetryPolicy（2）

是否足够，因为我没有深入挖掘驱动程序内部。可能会再次尝试向同一主机发送相同的请求。您可以尝试MyRetryPolicy（10），它至少可以显著减少失败次数

---

如果仍然存在一些故障（如1000个故障中的1个），则可能值得查看

com.datastax.driver.core.confirationpolicy

，查找它的用法并进一步调查。

Custom

RetryPolicy

是我尝试的第一件事，但是当抛出

NoHostAvailableException

时，它的回调方法都没有被调用。很抱歉，我的回答没有帮助。您是否尝试为com.datastax.driver.core.RequestHandler打开跟踪日志记录？看起来，当您关闭第一个节点时，第二个节点由于某种原因被抛出池。RequestHandler.logError（）方法（“错误查询bla bla bla bla”）中记录的异常堆栈跟踪可能有助于找到它。我将尝试一下，谢谢。