mynkow
mynkow

Reputation: 4548

How do I set the read timeout for a specific query in the C# driver?

Problem

I would like to set a timeout for a specific readonly query using the dotnet driver.

Context

I have a query likeselect count(*) from TABLE where ID=value

I am aware that:

Despite all this, I still want to run that query once every 3-4 months.

Requirements:

What I have tries I have big database locally on a single node. When I set a timeout to the query it is respected and everything works. In several minutes I got results. However, when I have a cluster of 5 nodes, a coordinator node gets the query and executes it against the other nodes and it hits 5 seconds timeout. Any timeouts which I have configured throught the driver for the socket or for the query are ignored. I also tried with all possible consistency levels. Also tried to use retry policy which ignores the errors.

Elders/Cronus.Persistence.Cassandra

Question Is it possible to set a timeout for a readonly query through the dotnet driver when cassandra is configured in a cluster?

Upvotes: 1

Views: 282

Answers (2)

Aaron
Aaron

Reputation: 57748

If I had to guess, the 5-second timeout sounds like the default value of read_request_timeout. So I would bet that this is getting cut off at the cluster level, regardless of what gets set for the driver config.

Have a look at your Cassandra nodes in the cassandra.yaml file for this value: read_request_timeout. It should be set to 5000ms.

Be careful in raising that too high. That value was picked for a reason, and ultimately is there to protect the cluster from queries that consume too many resources.

Upvotes: 0

Erick Ramirez
Erick Ramirez

Reputation: 16313

The client-side read timeout is configured with SocketOptions.SetReadTimeoutMillis() which by default is set to 12000 ms (12s).

You can override the timeout for a specific operation by calling Statement.SetReadTimeoutMillis() which is shared with all other statement types.

As a side note, a COUNT() is perfectly fine when the query is restricted to a single partition since it will simply count the rows within that partition. It won't cause a full table scan and doesn't suffer from the problems I discussed in Why COUNT() is bad in Cassandra. Cheers!

Upvotes: 1

Related Questions