MultipleRetry policy may retry with an incorrect Consistency level

Description

The MultipleRetry policy always retries with the consistency level coming back from Cassandra, i.e. the one the RetryPolicy callback is called with in onReadTimeout/onUnavailable/etc..

It turns out that in the case of a LWT, Cassandra may return the consistency level it was using during the current phase it encountered the error, e.g. if the error happens during the Paxos phase of a LWT, the consistency lever returned here would be SERIAL or LOCAL_SERIAL, as mentioned here.

So returning a RetryDecision.retry(null) instead of RetryDecision.retry(cl) (cl being the consistency level provided in the callback of the RetryPolicy) would indicate to the Java driver to retry with the statement's original consistency level, and not the one returned by Cassandra.

Environment

None

Pull Requests

None

Activity

Show:

Russell Spitzer June 14, 2017 at 10:20 PM

Switched CL to "null" but avoided tryNextHost because of the localNodeFirst policy ... it may make sense to change this in the future ...

Kevin Gallardo May 30, 2017 at 7:29 PM

I also looked at the MultipleRetryPolicy and saw this comment in onUnavailable:

Just wanted to mention that the driver now has a RetryDecision.tryNextHost(ConsistencyLevel cl) in case that may be useful.

Fixed

Details

Assignee

Reporter

Fix versions

Reviewer

Pull Request

Components

Affects versions

Priority

Created May 30, 2017 at 7:26 PM
Updated July 9, 2017 at 2:55 PM
Resolved July 7, 2017 at 5:38 PM