根据文档和互联网上的知识。看来下面给出的属性
- request_timeout_in_ms
- write_request_timeout_in_ms
- read_request_timeout_in_ms
仅适用于内部（服务器端）Cassandra请求。当我在cassandra.yaml文件中将这些参数设置为80000时，我甚至确信这一事实，但仍然通过以下两种方式将针对我的Select查询的超时错误更大的记录：
1）当我尝试通过cqlsh连接到Cassandra时没有附加参数--request-timeout=80000。通过添加此参数，我能够成功运行上次失败的选择状态。
2）当我尝试使用Cassandra驱动程序通过Java客户端更新同一记录而未在new SocketOptions().setReadTimeoutMillis(80000)创建中设置Cluster.Builder时。
问题：
是否有办法将这些request_timeout参数设置为Cassandra以用于外部（客户端）请求（所以我不必在通过Cqlsh或javaclient或DevCenter通过DataStax连接时提及这些值）？
答案 0 :(得分：1)
服务器也不能真正强制执行客户端超时，因为服务器外部会发生延迟。一个例子是Linux内核在发送请求时引入的延迟，然后是300毫秒的延迟峰值交叉DC，您的客户端在应用程序发送请求后500毫秒收到请求。
更糟糕的是与GC一起发挥作用，即C *发送响应，但随后有2秒STW gc暂停。该请求已经完成＆＃34;从服务器角度来看，客户端将有额外的2秒延迟。如果您的服务器配置不当，您可以定期看到8秒GC。服务器端的超时是最好的，因为它可以处理其控制之外的不可知（或至少令人难以置信）因素。如果你有一个严格的超时，最好在客户端处理它。我建议你在请求处理程序中执行它。
ListenableFuture result = Futures.withTimeout(session.executeAsync(/*statement*/),
8, TimeUnit.SECONDS, executor)
setReadTimeoutMillis有点细微差别，它的每个请求但execute/executeAsync最终可能会成为多个请求，因为它会尝试多个主机作为查询计划的一部分（重试/推测重试）。因此，例如，对于setReadTimeoutMillis为2的LOCAL_ONE上的RF = 3请求实际上可能需要6秒才能超时，具体取决于重试策略。