com.datastax.driver.core.policies

Class DowngradingConsistencyRetryPolicy

java.lang.Object

com.datastax.driver.core.policies.DowngradingConsistencyRetryPolicy

All Implemented Interfaces:

RetryPolicy

public class DowngradingConsistencyRetryPolicy
extends Object
implements RetryPolicy

A retry policy that sometimes retry with a lower consistency level than the one initially requested.

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 implements 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 being 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 information 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).

In other words, this policy implements the idea that if the requested consistency level cannot be achieved, the next best thing for writes is to make sure the data is persisted, and that reading something is better than reading nothing, even if there is a risk of reading stale data.

Nested Class Summary

Nested classes/interfaces inherited from interface com.datastax.driver.core.policies.RetryPolicy

RetryPolicy.RetryDecision

Field Summary

Fields

Modifier and Type	Field and Description
static DowngradingConsistencyRetryPolicy	INSTANCE

Method Summary

Methods

Modifier and Type	Method and Description
RetryPolicy.RetryDecision	onReadTimeout(Statement statement, ConsistencyLevel cl, int requiredResponses, int receivedResponses, boolean dataRetrieved, int nbRetry) Defines whether to retry and at which consistency level on a read timeout.
RetryPolicy.RetryDecision	onUnavailable(Statement statement, ConsistencyLevel cl, int requiredReplica, int aliveReplica, int nbRetry) Defines whether to retry and at which consistency level on an unavailable exception.
RetryPolicy.RetryDecision	onWriteTimeout(Statement statement, ConsistencyLevel cl, WriteType writeType, int requiredAcks, int receivedAcks, int nbRetry) Defines whether to retry and at which consistency level on a write timeout.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Detail

INSTANCE

public static final DowngradingConsistencyRetryPolicy INSTANCE

Method Detail

onReadTimeout

public RetryPolicy.RetryDecision onReadTimeout(Statement statement,
                                      ConsistencyLevel cl,
                                      int requiredResponses,
                                      int receivedResponses,
                                      boolean dataRetrieved,
                                      int nbRetry)

Defines whether to retry and at which consistency level on a read timeout.

This method triggers a maximum of one retry. If less replica responded 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.

Specified by:

onReadTimeout in interface RetryPolicy

Parameters:

statement - the original query that timeouted.

cl - the original consistency level of the read that timeouted.

requiredResponses - the number of responses that were required to achieve the requested consistency level.

receivedResponses - the number of responses that had been received by the time the timeout exception was raised.

dataRetrieved - whether actual data (by opposition to data checksum) was present in the received responses.

nbRetry - the number of retry already performed for this operation.

Returns:

a RetryDecision as defined above.

onWriteTimeout

public RetryPolicy.RetryDecision onWriteTimeout(Statement statement,
                                       ConsistencyLevel cl,
                                       WriteType writeType,
                                       int requiredAcks,
                                       int receivedAcks,
                                       int nbRetry)

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

Specified by:

onWriteTimeout in interface RetryPolicy

Parameters:

statement - the original query that timeouted.

cl - the original consistency level of the write that timeouted.

writeType - the type of the write that timeouted.

requiredAcks - the number of acknowledgments that were required to achieve the requested consistency level.

receivedAcks - the number of acknowledgments that had been received by the time the timeout exception was raised.

nbRetry - the number of retry already performed for this operation.

Returns:

a RetryDecision as defined above.

onUnavailable

public RetryPolicy.RetryDecision onUnavailable(Statement statement,
                                      ConsistencyLevel cl,
                                      int requiredReplica,
                                      int aliveReplica,
                                      int nbRetry)

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.

Specified by:

onUnavailable in interface RetryPolicy

Parameters:

statement - the original query for which the consistency level cannot be achieved.

cl - the original consistency level for the operation.

requiredReplica - the number of replica that should have been (known) alive for the operation to be attempted.

aliveReplica - the number of replica that were know to be alive by the coordinator of the operation.

nbRetry - the number of retry already performed for this operation.

Returns:

a RetryDecision as defined above.