Java Cassandra读取请求超时设置为外部（客户端）请求

根据文件和互联网上的已知知识。似乎下面给出的属性

- request_timeout_in_ms

- write_request_timeout_in_ms

- read_request_timeout_in_ms

仅适用于内部（服务器端）Cassandra请求。当我在

cassandra.yaml

文件中将这些参数设置为

80000

时，我甚至确信了这一事实，但仍然通过以下两种方式获得了Select查询的超时错误，使记录变大了一点：

1）当我试图通过cqlsh连接到Cassandra时，没有附加参数

——请求超时=80000

。通过添加此参数，我能够成功运行上次失败的select STATT。

2）当我试图通过java客户端使用Cassandra驱动程序更新同一条记录时，没有设置

new SocketOptions（）。在
Cluster.Builder
创建中设置readtimeoutmillis（80000）

。

问题：

---

对于外部（客户端）请求，是否有办法将这些请求超时参数设置为Cassandra（因此，在通过Cqlsh或javaclient或DataStax的DevCenter连接时，我不必提及这些值）？

服务器也不能真正强制客户端超时，因为在服务器外部会发生延迟。一个例子是linux内核在发送请求时引入的延迟，然后是300毫秒的延迟尖峰交叉DC，您的客户端在应用程序发送请求500毫秒后收到请求

更糟糕的是GCs，即C*发送响应，但随后有2秒的STW gc暂停。请求已从服务器角度“完成”，但客户端将有额外的2秒延迟。如果您的服务器配置不好，您可以很容易地定期看到8秒的GC。服务器端的超时是最好的，因为它可以处理给定的不可知（或至少是禁止性的不可知）因素，这些因素超出了它的控制范围。如果有严格的超时，最好在客户端处理。我建议您在请求处理程序中执行此操作

ListenableFuture result = Futures.withTimeout(session.executeAsync(/*statement*/),
                                              8, TimeUnit.SECONDS, executor)

---

setReadTimeoutMillis

有点细微差别，它是每个请求的，但是

executeAsync

可能会成为多个请求，因为它可能会尝试多个主机作为查询计划的一部分（重试/推测性重试）。因此，例如，本地_ONE上的RF=3请求的

setReadTimeoutMillis

值为2实际上可能需要6秒才能超时，这取决于重试策略。

在客户端级别可用的原因是提供灵活性，特别是不受服务器设置的控制。解释得很好@Chris。您提到要使用ListenableFuture。使用新的SocketOptions（）是否有任何区别。setReadTimeoutMillis（95000）；而不是ListenableFuture？在setReadTimeoutMillis中，您将对代码中的所有查询使用相同的超时。但是，listenablefuture仅限于特定的查询，因为所有查询都不需要相同的大超时。我更新了一个关于setReadTimeoutMillis的注释，它不一定会限制您的请求time@ChakriStark为整个查询添加setReadTimeoutMillis是否有任何开销？如果没有，我为什么要做额外的工作来把它们分开呢？@Freak根本没有开销。。我只是在前面的评论中解释你的问题的基本区别