You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Ekaterina Dimitrova (Jira)" <ji...@apache.org> on 2022/07/15 14:24:00 UTC
[jira] [Comment Edited] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[ https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17567262#comment-17567262 ]
Ekaterina Dimitrova edited comment on CASSANDRA-17530 at 7/15/22 2:23 PM:
--------------------------------------------------------------------------
I think this was already committed? Probably just forgot to close the ticket?
I was about to review it but then I noticed the commit.
Side note: the CircleCI patch files need to be recreated to get rid of the offset warnings we currently see when we apply MIDRES or HIGHRES.
This can be done using the following script:
#
# apply old patches (with hunk messages)
patch -o config-2_1.yml.MIDRES config-2_1.yml config-2_1.yml.mid_res.patch
patch -o config-2_1.yml.HIGHRES config-2_1.yml config-2_1.yml.high_res.patch
# generate new patches
diff -u config-2_1.yml config-2_1.yml.HIGHRES > config-2_1.yml.high_res.patch
diff -u config-2_1.yml config-2_1.yml.MIDRES > config-2_1.yml.mid_res.patch
# verify that the new patches generate the same files and cleanup
./generate.sh -a
The last step should confirm for you only the patch files are new but the MIDRES and HIGHRES were not changed.
was (Author: e.dimitrova):
I think this was already committed? Probably just forgot to close the ticket?
I was about to review it but then I noticed the commit.
Side note: the CircleCI patch files need to be recreated to get rid of the offset warnings we currently see when we apply MIDRES or HIGHRES.
This can be done using the following script:
# apply old patches (with hunk messages)
patch -o config-2_1.yml.MIDRES config-2_1.yml config-2_1.yml.mid_res.patch
patch -o config-2_1.yml.HIGHRES config-2_1.yml config-2_1.yml.high_res.patch
# generate new patches
diff -u config-2_1.yml config-2_1.yml.HIGHRES > config-2_1.yml.high_res.patch
diff -u config-2_1.yml config-2_1.yml.MIDRES > config-2_1.yml.mid_res.patch
# verify that the new patches generate the same files and cleanup
./generate.sh -a
The last step should confirm for you only the patch files are new but the MIDRES and HIGHRES were not changed.
> Paxos v2 Linearizability Violation
> ----------------------------------
>
> Key: CASSANDRA-17530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17530
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
> Reporter: Benedict Elliott Smith
> Assignee: Benedict Elliott Smith
> Priority: Normal
> Fix For: 4.1-rc
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The version of Paxos introduced recently had a subtle mistake that introduced a linearizability flaw that has been detected by the simulator, and also a flaw with the simulator has been found that may erroneously report a linearizability violation.
> The true linearizability fault is quite simple: fast read permissions were erroneously being escalated to promises when an incomplete proposal was discovered. This was likely due in part to the naming of the state {{FOUND_INCOMPLETE_ACCEPTED}} which does not communicate that the ballot will be used to re-propose this proposal using the promises we have obtained. The fix is to yield {{SUPERSEDED}} if {{!haveOnlyPromises}}.
> The false linearizability fault was triggered when two different competing incomplete proposals were reproposed multiple times, with the winning proposal being the one with the lower original ballot, and the proposal with the higher ballot having been successfully proposed to a majority of nodes but across multiple different ballots (so that no single ballot reached a majority), while the most recently successful ballot (at a minority) was the older original ballot. The range movement validation logic looked only at the original ballot, and since it saw the higher original ballot as having reached a majority perceived that it should have become persistent, when in fact the older ballot did so.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org