@Deprecated 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 are 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 breaks.
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 operations, if at least one replica acknowledged the write, the
timeout is ignored.
THREE
.
ONE
, TWO
or
THREE
.
EACH_QUORUM
, Cassandra returns the number
of live replicas in the datacenter that failed to reach consistency, not the overall
number in the cluster. Therefore if this number is 0, we still retry at ONE
, on the
assumption that a host may still be up in another datacenter.
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 chance to succeed, do it. Otherwise, if based on this information we know the initially requested consistency level cannot be achieved currently, then:
RetryPolicy.RetryDecision
Modifier and Type | Field and Description |
---|---|
static DowngradingConsistencyRetryPolicy |
INSTANCE
Deprecated.
|
Modifier and Type | Method and Description |
---|---|
void |
close()
Deprecated.
Gets invoked at cluster shutdown.
|
void |
init(Cluster cluster)
Deprecated.
Gets invoked at cluster startup.
|
RetryPolicy.RetryDecision |
onReadTimeout(Statement statement,
ConsistencyLevel cl,
int requiredResponses,
int receivedResponses,
boolean dataRetrieved,
int nbRetry)
Deprecated.
Defines whether to retry and at which consistency level on a read timeout.
|
RetryPolicy.RetryDecision |
onRequestError(Statement statement,
ConsistencyLevel cl,
DriverException e,
int nbRetry)
Deprecated.
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)
Deprecated.
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)
Deprecated.
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)
Note that this method may be called even if requiredResponses >= receivedResponses
if dataPresent
is false
(see ReadTimeoutException.wasDataRetrieved()
).
This implementation triggers a maximum of one retry. If less replicas 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 replicas responded but data was not retrieved, the operation is retried with the initial consistency level. Otherwise, an exception is thrown.
onReadTimeout
in interface RetryPolicy
statement
- 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.RETHROW
is returned, a ReadTimeoutException
will be thrown for the operation.public RetryPolicy.RetryDecision onWriteTimeout(Statement statement, ConsistencyLevel cl, WriteType writeType, int requiredAcks, int receivedAcks, int nbRetry)
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 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 RetryPolicy
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, 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.RETHROW
is returned, a WriteTimeoutException
will be thrown for the
operation.public RetryPolicy.RetryDecision onUnavailable(Statement statement, ConsistencyLevel cl, int requiredReplica, int aliveReplica, int nbRetry)
This implementation triggers a maximum of one retry. If at least one replica is known to be alive, the operation is retried at a lower consistency level.
onUnavailable
in interface RetryPolicy
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, 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)
This method might be invoked in the following situations:
SocketOptions.getReadTimeoutMillis()
);
OVERLOADED
error, SERVER_ERROR
,
READ_FAILURE
or WRITE_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).
For historical reasons, this implementation triggers a retry on the next host in the query
plan with the same consistency level, regardless of the statement's idempotence. Note that this
breaks the general rule stated in RetryPolicy.onRequestError(Statement,
ConsistencyLevel, DriverException, int)
: "a retry should only be attempted if the request is
known to be idempotent".`
onRequestError
in interface RetryPolicy
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 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)
RetryPolicy
init
in interface RetryPolicy
cluster
- the cluster that this policy is associated with.public void close()
RetryPolicy
This gives the policy the opportunity to perform some cleanup, for instance stop threads that it might have started.
close
in interface RetryPolicy
Copyright © 2012–2019. All rights reserved.