public class DefaultRetryPolicy extends Object implements RetryPolicy
DowngradingConsistencyRetryPolicy.RetryPolicy.RetryDecision| Modifier and Type | Field and Description | 
|---|---|
| static DefaultRetryPolicy | 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 | onRequestError(Statement statement,
              ConsistencyLevel cl,
              DriverException e,
              int nbRetry)Defines whether to retry and at which consistency level on an
 unexpected error. | 
| 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 DefaultRetryPolicy INSTANCE
public RetryPolicy.RetryDecision onReadTimeout(Statement statement, ConsistencyLevel cl, int requiredResponses, int receivedResponses, boolean dataRetrieved, int nbRetry)
requiredResponses >= receivedResponses if dataPresent is
 false (see
 ReadTimeoutException.wasDataRetrieved()).
 
 This implementation triggers a maximum of one retry, and only if enough
 replicas 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 chance of success.onReadTimeout in interface RetryPolicystatement - the original query that timed out.cl - the requested consistency level of the read that timed out.
                          Note that this can never be a serial
                          consistency level.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.RetryDecision.retry(cl) if no retry attempt has yet been tried and
 receivedResponses >= requiredResponses && !dataRetrieved, RetryDecision.rethrow() otherwise.public RetryPolicy.RetryDecision onWriteTimeout(Statement statement, ConsistencyLevel cl, WriteType writeType, int requiredAcks, int receivedAcks, int nbRetry)
not idempotent, the driver will never retry it on a
 write timeout (this method won't even be called).
 
 This implementation 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 nodes 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 chance of success.onWriteTimeout in interface RetryPolicystatement - the original query that timed out.cl - the requested consistency level of the write that timed out.
                     If the timeout occurred at the "paxos" phase of a
                     Lightweight transaction,
                     then cl will actually be the requested serial consistency level.
                     Beware that serial consistency levels should never be passed to a RetryDecision as this would
                     invariably trigger an InvalidQueryException.
                     Also, when cl is serial, then writeType is always CAS.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.RetryDecision.retry(cl) if no retry attempt has yet been tried and
 writeType == WriteType.BATCH_LOG, RetryDecision.rethrow() otherwise.public RetryPolicy.RetryDecision onUnavailable(Statement statement, ConsistencyLevel cl, int requiredReplica, int aliveReplica, int nbRetry)
nbRetry == 0), it triggers a retry on the next host in the query plan
 with the same consistency level (RetryDecision#tryNextHost(null).
 The rationale is that the first coordinator might have been network-isolated from all other nodes (thinking
 they're down), but still able to communicate with the client; in that case, retrying on the same host has almost
 no chance of success, but moving to the next host might solve the issue.onUnavailable in interface RetryPolicystatement - the original query for which the consistency level cannot
                        be achieved.cl - the requested consistency level for the operation.
                        If the operation failed at the "paxos" phase of a
                        Lightweight transaction,
                        then cl will actually be the requested serial consistency level.
                        Beware that serial consistency levels should never be passed to a RetryDecision as this would
                        invariably trigger an InvalidQueryException.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.RetryDecision.RETHROW is returned,
 an UnavailableException will
 be thrown for the operation.public RetryPolicy.RetryDecision onRequestError(Statement statement, ConsistencyLevel cl, DriverException e, int nbRetry)
SocketOptions.getReadTimeoutMillis());OVERLOADED error or a SERVER_ERROR.not idempotent, the driver will never retry it
 (this method won't even be called).onRequestError in interface RetryPolicystatement - the original query that failed.cl - the requested consistency level for the operation.
                  Note that this is not necessarily the achieved consistency level (if any),
                  and it is never a serial one.e - the exception that caused this request to fail.nbRetry - the number of retries already performed for this operation.RetryDecision.RETHROW is returned,
 the DriverException passed to this method will be thrown for the 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–2017. All rights reserved.