[ https://issues.apache.org/jira/browse/CASSANDRA-12126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631226#comment-16631226 ]
Benedict commented on CASSANDRA-12126: -------------------------------------- bq. We read nothing in node Y, yet node Z read something in the next request. I think the problem here is that, at the API level, there isn't enough information to say that X didn't simply 'occur' *after* both Y and Z. That is, unless the rejection of Y occurs after X's timeout. In this case, it would seem to be an API-visible error, as at the point of timeout the indeterminacy should be fixed. Timeouts should not ‘live forever’ as the bogeyman, ready to mess with history. I think, though, that the suggested mechanism could result in this. Take three nodes (RF=3) A, B and C; and any three CAS operations X, Y and Z such that: * X and Y can always succeed * Z can only succeed if X has succeeded Setup: # Prepare _and_ Propose X with ballot 1; proposal accepted only by A #* this will be the last and only node’s proposal acceptance # Prepare Y with ballot 2; reach B and C before ballot 1, so they do not accept # Now, lock X and Y in battle, always failing to proceed to the propose step before the other reaches the prepare step again # X and Y both timeout having failed to cleanly apply Part 2: # Z is now attempted; it prepares to only B and C, seeing no in-progress proposal # As a result, it does not see X; it is rejected, so there is no new proposal/commit # Read at SERIAL is performed; this time, A is consulted # Suddenly, a wild X appears. From nowhere. It does seem, in essence, to be an incidence of the bug (or a very similar one) described in the ticket. > CAS Reads Inconsistencies > -------------------------- > > Key: CASSANDRA-12126 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12126 > Project: Cassandra > Issue Type: Bug > Components: Coordination > Reporter: sankalp kohli > Priority: Major > Labels: LWT > > While looking at the CAS code in Cassandra, I found a potential issue with > CAS Reads. Here is how it can happen with RF=3 > 1) You issue a CAS Write and it fails in the propose phase. A machine replies > true to a propose and saves the commit in accepted filed. The other two > machines B and C does not get to the accept phase. > Current state is that machine A has this commit in paxos table as accepted > but not committed and B and C does not. > 2) Issue a CAS Read and it goes to only B and C. You wont be able to read the > value written in step 1. This step is as if nothing is inflight. > 3) Issue another CAS Read and it goes to A and B. Now we will discover that > there is something inflight from A and will propose and commit it with the > current ballot. Now we can read the value written in step 1 as part of this > CAS read. > If we skip step 3 and instead run step 4, we will never learn about value > written in step 1. > 4. Issue a CAS Write and it involves only B and C. This will succeed and > commit a different value than step 1. Step 1 value will never be seen again > and was never seen before. > If you read the Lamport “paxos made simple” paper and read section 2.3. It > talks about this issue which is how learners can find out if majority of the > acceptors have accepted the proposal. > In step 3, it is correct that we propose the value again since we dont know > if it was accepted by majority of acceptors. When we ask majority of > acceptors, and more than one acceptors but not majority has something in > flight, we have no way of knowing if it is accepted by majority of acceptors. > So this behavior is correct. > However we need to fix step 2, since it caused reads to not be linearizable > with respect to writes and other reads. In this case, we know that majority > of acceptors have no inflight commit which means we have majority that > nothing was accepted by majority. I think we should run a propose step here > with empty commit and that will cause write written in step 1 to not be > visible ever after. > With this fix, we will either see data written in step 1 on next serial read > or will never see it which is what we want. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org