Class FallthroughRetryPolicy
- java.lang.Object
-
- com.datastax.driver.core.policies.FallthroughRetryPolicy
-
- All Implemented Interfaces:
RetryPolicy
public class FallthroughRetryPolicy extends Object implements RetryPolicy
A retry policy that never retries (nor ignores).All of the methods of this retry policy unconditionally return
RetryPolicy.RetryDecision.rethrow(). If this policy is used, retry logic will have to be implemented in business code.
-
-
Nested Class Summary
-
Nested classes/interfaces inherited from interface com.datastax.driver.core.policies.RetryPolicy
RetryPolicy.RetryDecision
-
-
Field Summary
Fields Modifier and Type Field Description static FallthroughRetryPolicyINSTANCE
-
Method Summary
All Methods Instance Methods Concrete Methods Modifier and Type Method Description voidclose()Gets invoked at cluster shutdown.voidinit(Cluster cluster)Gets invoked at cluster startup.RetryPolicy.RetryDecisiononReadTimeout(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.RetryDecisiononRequestError(Statement statement, ConsistencyLevel cl, DriverException e, int nbRetry)Defines whether to retry and at which consistency level on an unexpected error.RetryPolicy.RetryDecisiononUnavailable(Statement statement, ConsistencyLevel cl, int requiredReplica, int aliveReplica, int nbRetry)Defines whether to retry and at which consistency level on an unavailable exception.RetryPolicy.RetryDecisiononWriteTimeout(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.
-
-
-
Field Detail
-
INSTANCE
public static final FallthroughRetryPolicy 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.Note that this method may be called even if
requiredResponses >= receivedResponsesifdataPresentisfalse(seeReadTimeoutException.wasDataRetrieved()).This implementation always returns
RetryDecision.rethrow().- Specified by:
onReadTimeoutin interfaceRetryPolicy- Parameters:
statement- the original query that timed out.cl- the requested consistency level of the read that timed out. Note that this can never be aserialconsistency 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.- Returns:
- the retry decision. If
RetryDecision.RETHROWis returned, aReadTimeoutExceptionwill be thrown for the operation.
-
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.Note that if a statement is
not idempotent, the driver will never retry it on a write timeout (this method won't even be called).This implementation always returns
RetryDecision.rethrow().- Specified by:
onWriteTimeoutin interfaceRetryPolicy- Parameters:
statement- 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, thenclwill actually be the requestedserialconsistency level. Beware that serial consistency levels should never be passed to aRetryDecisionas this would invariably trigger anInvalidQueryException. Also, whenclisserial, thenwriteTypeis alwaysCAS.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.- Returns:
- the retry decision. If
RetryDecision.RETHROWis returned, aWriteTimeoutExceptionwill be thrown for the operation.
-
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 implementation always returns
RetryDecision.rethrow().- Specified by:
onUnavailablein interfaceRetryPolicy- Parameters:
statement- 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, thenclwill actually be the requestedserialconsistency level. Beware that serial consistency levels should never be passed to aRetryDecisionas this would invariably trigger anInvalidQueryException.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:
- the retry decision. If
RetryDecision.RETHROWis returned, anUnavailableExceptionwill be thrown for the operation.
-
onRequestError
public RetryPolicy.RetryDecision onRequestError(Statement statement, ConsistencyLevel cl, DriverException e, int nbRetry)
Defines whether to retry and at which consistency level on an unexpected error.This method might be invoked in the following situations:
- On a client timeout, while waiting for the server response (see
SocketOptions.getReadTimeoutMillis()); - On a connection error (socket closed, etc.);
- When the contacted host replies with an
OVERLOADEDerror,SERVER_ERROR,READ_FAILUREorWRITE_FAILURE.
Note that when such an error occurs, there is no guarantee that the mutation has been applied server-side or not. Therefore, if a statement is
not idempotent, the driver will never retry it (this method won't even be called).This implementation always returns
RetryDecision.rethrow().- Specified by:
onRequestErrorin interfaceRetryPolicy- Parameters:
statement- 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 aserialone.e- the exception that caused this request to fail.nbRetry- the number of retries already performed for this operation.- Returns:
- the retry decision. If
RetryDecision.RETHROWis returned, theDriverExceptionpassed to this method will be thrown for the operation.
- On a client timeout, while waiting for the server response (see
-
init
public void init(Cluster cluster)
Description copied from interface:RetryPolicyGets invoked at cluster startup.- Specified by:
initin interfaceRetryPolicy- Parameters:
cluster- the cluster that this policy is associated with.
-
close
public void close()
Description copied from interface:RetryPolicyGets invoked at cluster shutdown.This gives the policy the opportunity to perform some cleanup, for instance stop threads that it might have started.
- Specified by:
closein interfaceRetryPolicy
-
-