| DowngradingConsistencyRetryPolicy Class |
BEWARE: This policy may retry queries using a lower consistency level than the one initially requested. By doing so, it may break consistency guarantees. In other words, if you use this retry policy, there is cases (documented below) where a read at Quorum may not see a preceding write at Quorum. Do not use this policy unless you have understood the cases where this can happen and are OK with that. It is also highly recommended to always wrap this policy into LoggingRetryPolicy to log the occurrences of such consistency break.
This policy : the same retries than the DefaultRetryPolicy policy. But on top of that, it also retries in the following cases:
- On a read timeout: if the number of replica that responded is greater than one but lower than is required by the requested consistency level, the operation is retried at a lower consistency level.
- On a write timeout: if the operation is an WriteType.UNLOGGED_BATCH and at least one replica acknowledged the write, the operation is retried at a lower consistency level. Furthermore, for other operation, if at least one replica acknowledged the write, the timeout is ignored.
- On an unavailable exception: if at least one replica is alive, the operation is retried at a lower consistency level.
The reasoning behind this retry policy is the following one. If, based on the information the Cassandra coordinator node returns, retrying the operation with the initially requested consistency has a change to succeed, do it. Otherwise, if based on these informations we know the initially requested consistency level cannot be achieve currently, then:
- For writes, ignore the exception (thus silently failing the consistency requirement) if we know the write has been persisted on at least one replica.
- For reads, try reading at a lower consistency level (thus silently failing the consistency requirement).
Inheritance HierarchyCassandraDowngradingConsistencyRetryPolicy
Namespace: Cassandra
Assembly: Cassandra (in Cassandra.dll) Version: 3.2.0
Syntaxpublic class DowngradingConsistencyRetryPolicy : IRetryPolicy
The DowngradingConsistencyRetryPolicy type exposes the following members.
Methods| Name | Description | |
|---|---|---|
 | Equals | Determines whether the specified object is equal to the current object. (Inherited from Object.) |
| GetHashCode | Serves as the default hash function. (Inherited from Object.) |
| GetType | Gets the Type of the current instance. (Inherited from Object.) |
| OnReadTimeout |
Defines whether to retry and at which consistency level on a read timeout.
This method triggers a maximum of one retry. If less replica responsed than required by the consistency level (but at least one replica did respond), the operation is retried at a lower consistency level. If enough replica responded but data was not retrieve, the operation is retried with the initial consistency level. Otherwise, an exception is thrown. |
| OnUnavailable |
Defines whether to retry and at which consistency level on an unavailable
exception. This method triggers a maximum of one retry. If at least one replica is know to be alive, the operation is retried at a lower consistency level. |
| OnWriteTimeout |
Defines whether to retry and at which consistency level on a write timeout.
This method triggers a maximum of one retry. If writeType == WriteType.BATCH_LOG, the write is retried with the initial consistency level. If writeType == WriteType.UNLOGGED_BATCH and at least one replica acknowleged, the write is retried with a lower consistency level (with unlogged batch, a write timeout can always mean that part of the batch haven't been persisted at' all, even if receivedAcks > 0). For other writeType, if we know the write has been persisted on at least one replica, we ignore the exception. Otherwise, an exception is thrown. |
| ToString | Returns a string that represents the current object. (Inherited from Object.) |
Fields
See Also