为外部（客户端）请求设置了Cassandra read_request_timeout_in_ms [英] Cassandra read_request_timeout_in_ms set up for external(Client) request

问题描述

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

As per Documentation and given knowledge on the internet. It seems that the below-given properties

- 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）当我尝试通过Java客户端使用Cassandra驱动程序更新同一记录而未设置 new SocketOptions（）时.setReadTimeoutMillis（80000）在 Cluster.Builder 创建中。


问题：

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

Works only for internal(server side) Cassandra requests. I was even convinced to this fact when I set these parameters in cassandra.yaml file to 80000 but still got the Timeout error against my Select query to a bit bigger record by following two ways:

1) when I tried to connect to Cassandra via cqlsh without additional parameter --request-timeout=80000. by adding this parameter, I was able to run select statment successfully which was being failed last time.

2) When I tried to update the same record via java client using Cassandra driver without setting up new SocketOptions().setReadTimeoutMillis(80000) in Cluster.Builder creation.

Question:
Is there are way to set these request_timeout parameters to Cassandra for external(client side) requests as well (So I don't have to mention these values while connecting via Cqlsh or javaclient or DevCenter by DataStax)?

推荐答案

服务器也无法真正强制执行客户端超时，因为服务器外部会发生延迟。一个例子是linux内核在发送请求时引入了延迟，然后DC出现了300ms的延迟尖峰，您的客户端在应用程序发送请求后500ms收到了请求。

The server cant really enforce a client side timeout as well, as there are delays that occur outside the server. An example is a delay introduced by the linux kernel in sending the request, then a 300ms latency spike cross DC, your client is getting the request 500ms after the app sent it.

更糟糕的是，GC发挥了作用，即C *发送了响应，但是有2秒的STW gc暂停。从服务器的角度来看，该请求已完成，但客户端将有2秒的额外延迟。如果您的服务器配置不正确，您可以轻松地定期看到8秒的GC。服务器端的超时是最大的，它可以处理其控制范围之外的给定（至少是令人无法接受的）因素。如果超时时间很长，最好在客户端进行处理。我建议在您的请求处理程序中执行此操作。

Worse comes in play with GCs, ie C* sends the response, but then has a 2 second STW gc pause. The request has been "completed" from server perspective but the client will have an additional 2 second delay. If your server is poorly configured you can easily see a 8 second GC periodically. The timeout on the server side is as best as it can handle given unknowable (or prohibitively unknowable at least) factors outside its control. If you have a strict timeout its best to handle it on the client side. I would recommend doing it in your request handler.

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

setReadTimeoutMillis 有点细微差别，它的每个请求都很细微，但是 execute / executeAsync 最终可能是多个请求，因为它将作为潜在一部分尝试多个主机查询计划（重试/推测性重试）。因此，例如，根据重试策略，在LOCAL_ONE上的RF = 3请求，其中 setReadTimeoutMillis 为2的超时实际上可能需要6秒钟。

setReadTimeoutMillis is a little nuanced, its per request but a execute/executeAsync can end up being multiple requests, as it will try multiple hosts potentially as part of query plan (retry/speculative retry). So for example a RF=3 request on LOCAL_ONE with setReadTimeoutMillis of 2 could actually take 6 seconds to timeout depending on retry policy.

这篇关于为外部（客户端）请求设置了Cassandra read_request_timeout_in_ms的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！