DefaultRetryPolicy Class

The default retry policy.

This policy retries queries in only two cases:

On a read timeout, if enough replica replied but data was not retrieved.
On a write timeout, if we timeout while writting the distributed log used by batch statements.

This retry policy is conservative in that it will never retry with a different consistency level than the one of the initial operation.

In some cases, it may be convenient to use a more aggressive retry policy like DowngradingConsistencyRetryPolicy.

Inheritance Hierarchy

SystemObject
CassandraDefaultRetryPolicy

Namespace: Cassandra
Assembly: Cassandra (in Cassandra.dll) Version: 3.0.9 (git 5ca22bb)

Syntax

public class DefaultRetryPolicy : IRetryPolicy

The DefaultRetryPolicy type exposes the following members.

Constructors

	Name	Description
	DefaultRetryPolicy	Initializes a new instance of the DefaultRetryPolicy class

Methods

	Name	Description
	OnReadTimeout	Defines whether to retry and at which consistency level on a read timeout. This method triggers a maximum of one retry, and only if enough replica had responded to the read request but data was not retrieved amongst those. Indeed, that case usually means that enough replica are alive to satisfy the consistency but the coordinator picked a dead one for data retrieval, not having detected that replica as dead yet. The reasoning for retrying then is that by the time we get the timeout the dead replica will likely have been detected as dead and the retry has a high change of success.
	OnUnavailable	Defines whether to retry and at which consistency level on an unavailable exception. This method never retries as a retry on an unavailable exception using the same consistency level has almost no change of success.
	OnWriteTimeout	Defines whether to retry and at which consistency level on a write timeout. This method triggers a maximum of one retry, and only in the case of a WriteType.BATCH_LOG write. The reasoning for the retry in that case is that write to the distributed batch log is tried by the coordinator of the write against a small subset of all the node alive in the local datacenter. Hence, a timeout usually means that none of the nodes in that subset were alive but the coordinator hasn't' detected them as dead. By the time we get the timeout the dead nodes will likely have been detected as dead and the retry has thus a high change of success.