public class DowngradingConsistencyRetryPolicy extends Object implements RetryPolicy
 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:
 
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.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:
RetryPolicy.RetryDecision| Modifier and Type | Field and Description | 
|---|---|
| static DowngradingConsistencyRetryPolicy | INSTANCE | 
| Modifier and Type | Method and Description | 
|---|---|
| void | close()Gets invoked at cluster shutdown. | 
| void | init(Cluster cluster)Gets invoked at cluster startup. | 
| 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. | 
public static final DowngradingConsistencyRetryPolicy INSTANCE
public RetryPolicy.RetryDecision onReadTimeout(Statement statement, ConsistencyLevel cl, int requiredResponses, int receivedResponses, boolean dataRetrieved, int nbRetry)
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.
onReadTimeout in interface RetryPolicystatement - the original query that timed out.cl - the original consistency level of the read that timed out.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.public RetryPolicy.RetryDecision onWriteTimeout(Statement statement, ConsistencyLevel cl, WriteType writeType, int requiredAcks, int receivedAcks, int nbRetry)
 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 write types (WriteType.SIMPLE
 and WriteType.BATCH), if we know the write has been persisted on at
 least one replica, we ignore the exception. Otherwise, an exception is thrown.
onWriteTimeout in interface RetryPolicystatement - the original query that timed out.cl - the original consistency level of the write that timed out.writeType - the type of the write that timed out.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.public RetryPolicy.RetryDecision onUnavailable(Statement statement, ConsistencyLevel cl, int requiredReplica, int aliveReplica, int nbRetry)
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.
onUnavailable in interface RetryPolicystatement - 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.public void init(Cluster cluster)
RetryPolicyinit in interface RetryPolicycluster - the cluster that this policy is associated with.public void close()
RetryPolicyclose in interface RetryPolicyCopyright © 2012–2015. All rights reserved.