[
https://issues.apache.org/jira/browse/CASSANDRA-12126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629685#comment-16629685
]
Jeffrey F. Lukman edited comment on CASSANDRA-12126 at 9/27/18 3:19 PM:
------------------------------------------------------------------------
To complete our scenario, here is the setup for our Cassandra:
We run the scenario with Cassandra-v2.0.15.
Here is the scheme that we use:
* CREATE KEYSPACE test WITH REPLICATION = \{'class': 'SimpleStrategy',
'replication_factor': 3};
* CREATE TABLE tests ( name text PRIMARY KEY, owner text, value_1 text,
value_2 text, value_3 text);
Here are the queries that we submit:
* client request to node X (1st): UPDATE test.tests SET value_1 = 'A' WHERE
name = 'testing' IF owner = 'user_1';
* client request to node Y (2nd): UPDATE test.tests SET value_2 = 'B' WHERE
name = 'testing' IF value_1 = 'A';
* client request to node Z (3rd): UPDATE test.tests SET value_3 = 'C' WHERE
name = 'testing' IF value_1 = 'A';
To confirm, when the bug is manifested, the end result will be: value_1='A',
value_2=null, value_3=null
[~jjirsa], regarding our tool, at this point, it is not open for public.
was (Author: jeffreyflukman):
To complete our scenario, here is the setup for our Cassandra:
We run the scenario with Cassandra-v2.0.15.
Here is the scheme that we use:
*
CREATE KEYSPACE test WITH REPLICATION = \{'class': 'SimpleStrategy',
'replication_factor': 3};
*
CREATE TABLE tests ( name text PRIMARY KEY, owner text, value_1 text, value_2
text, value_3 text);
Here are the queries that we submit:
* client request to node X (1st): UPDATE test.tests SET value_1 = 'A' WHERE
name = 'testing' IF owner = 'user_1';
* client request to node Y (2nd): UPDATE test.tests SET value_2 = 'B' WHERE
name = 'testing' IF value_1 = 'A';
* client request to node Z (3rd): UPDATE test.tests SET value_3 = 'C' WHERE
name = 'testing' IF value_1 = 'A';
To confirm, when the bug is manifested, the end result will be: value_1='A',
value_2=null, value_3=null
[~jjirsa], regarding our tool, at this point, it is not open for public.
> 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
