The Datastax Java Driver for Cassandra exposes its strategy for retrying via the following interface:
There are three scenarios you can control retry policy for:
- Read time out: When a coordinator received the request and sent the read to replica(s) but the replica(s) did
not respond in time
- Write timeout: As above but for writes
- Unavailable: When the coordinator is aware there aren't enough replica available without sending the read/write
What is the default behaviour?
The DefaultRetryPolicy retries with the following behaviour:
- Read timeout: When enough replica are available but the data did not come back within the configured read
- Write timeout: Only if the initial phase of a batch write times out - see cassandra batch statement
- Unavailable timeout: Never
How do I configure the value for the read and write timeout?
This is configured in the cassandra.yaml on the Cassandra server. The default is 10 seconds, you can
change the following properties:
# How long the coordinator should wait for read operations to complete
# How long the coordinator should wait for writes to complete
What are the other policies?
The most complicated retry policy and comes with a big
warning: your read/write may be re-tried at a lower consistency. So if you have business requirements to not report
success if you don't meet a certain level of consistency then use this with cation.
What does it do?
- Read: If at least one replica responded then the read is retried at a lower consistency
- Write: Retries for unlogged batch queries when at least one replica responded (see http://www.datastax.com/dev/blog/atomic-batches-in-cassandra-1-2)
and for all other types of writes the timeout is just ignored if at least one replica acknowledged the write
(essentially ignoring the consistency request)
- Unavailable: If at least one replica is available then the query is re-tried with a lower consistency
No retrying! Any failure is re-thrown to the client.
This is just a decorator policy that you can wrap
around any other policy that logs ignored (no retry) and any actual retries. The driver uses SLF4J and logs at INFO
How do I use a different policy?
Simply add it with creating your Cluster. The retry policies all have a singleton you can use e.g:
The Datastax driver is very open for extension as it exposes its strategies for retry, load balancing and
The retry policy is very easy to work with as all the current implementations are stateless. I'll follow this post
up with how to implement your own retry policy.