[jira] [Commented] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17637364#comment-17637364
]
Benedict Elliott Smith commented on CASSANDRA-17530:
It wasn't when the patch was prepared, but it looks like it was merged shortly
after alpha.
> 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-beta1, 4.1, 4.2
>
> 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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17637345#comment-17637345
]
Michael Semb Wever commented on CASSANDRA-17530:
bq. I don't think the bug didn't make it into any release, so was there any
change to note?
Was it not in {{4.1-alpha`}} ? (or have i misunderstood the since field field?)
> 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-beta1, 4.1, 4.2
>
> 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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17637326#comment-17637326
]
Benedict Elliott Smith commented on CASSANDRA-17530:
The bug didn't make it into a release, so there was no public change to note?
> 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-beta1, 4.1, 4.2
>
> 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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17637314#comment-17637314
]
Michael Semb Wever commented on CASSANDRA-17530:
Was there a {{CHANGES.txt}} entry for this? (There are runtime classes touched
here…)
> 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-beta
>
> 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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (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 commented on CASSANDRA-17530:
-
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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17566870#comment-17566870
]
Benedict Elliott Smith commented on CASSANDRA-17530:
Caleb noted a dtest failure resulting from this ticket. I have opened a PR to
address this, as it's a one line change, and fairly soon in follow-up:
https://github.com/apache/cassandra/pull/1733
I've flagged Sam, David and Blake as potential reviewers, but if anyone has the
time it should be very easy for anyone to +1.
> 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: 20m
> 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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17565434#comment-17565434
]
Benedict Elliott Smith commented on CASSANDRA-17530:
CircleCI: [java8
https://app.circleci.com/pipelines/github/belliottsmith/cassandra/307/workflows/4e71f806-e4eb-4869-aac1-d01d8a7a5bfe]
[java11|https://app.circleci.com/pipelines/github/belliottsmith/cassandra/307/workflows/f3c2d1f4-f821-48dd-943c-1e6c6cb7df44]
One unrelated failure, merging.
> 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: 20m
> 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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17530) Paxos v2 Linearizability Violation
[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556594#comment-17556594
]
Ekaterina Dimitrova commented on CASSANDRA-17530:
-
Triaging the 4.1 blockers and stumbled into this one. It seems a bit old
already. I believe it will need rebase and patches for both 4.1 and trunk plus
CI runs. :)
> 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
>
>
> 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.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
