Cassandra read_request_timeout_in_ms set up for ex

Question

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

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)?

Answer 1

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.

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 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.