[jira] [Updated] (CASSANDRA-6013) CAS may return false but still commit the insert
[ https://issues.apache.org/jira/browse/CASSANDRA-6013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-6013: Labels: LWT (was: ) > CAS may return false but still commit the insert > > > Key: CASSANDRA-6013 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6013 > Project: Cassandra > Issue Type: Bug >Reporter: Sylvain Lebresne >Assignee: Jonathan Ellis >Priority: Major > Labels: LWT > Fix For: 2.0.1 > > Attachments: 6013-v2.txt, 6013-v3.txt, 6013-v4.patch, 6013.txt > > > If a Paxos proposer proposes some value/update and that propose fail, there > is no guarantee on whether this value will be accepted or not ultimately. > Paxos guarantees that we'll agree on "a" value (for a given round in our > case), but does not guarantee that the proposer of the agreed upon value will > know it. In particular, if for a given proposal at least one accepter has > accepted it but not a quorum does, then that value might (but that's not > guaranteed either) be replayed (and committed) by another proposer. > Currently, if a proposer A proposes some update U but it is rejected, A will > sleep a bit and retry U. But if U was accepted by at least one acceptor, some > other proposer B might replay U, succeed and commit it. If A does its retry > after that happens, he will prepare, check the condition, and probably find > that the conditions don't apply anymore since U has been committed already. > It will thus return false, even though U has been in fact committed. > Unfortunately I'm not sure there is an easy way for a proposer whose propose > fails to know if the update will prevail or not eventually. Which mean the > only acceptable solution I can see would be to return to the user "I don't > know" (through some exception for instance). Which is annoying because having > a proposal rejected won't be an extremely rare occurrence, even with > relatively light contention, and returning "I don't know" often is a bit > unfriendly. -- 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
[jira] [Updated] (CASSANDRA-6013) CAS may return false but still commit the insert
[ https://issues.apache.org/jira/browse/CASSANDRA-6013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6013: -- Attachment: 6013-v3.txt CAS may return false but still commit the insert Key: CASSANDRA-6013 URL: https://issues.apache.org/jira/browse/CASSANDRA-6013 Project: Cassandra Issue Type: Bug Reporter: Sylvain Lebresne Assignee: Jonathan Ellis Fix For: 2.0.1 Attachments: 6013.txt, 6013-v2.txt, 6013-v3.txt If a Paxos proposer proposes some value/update and that propose fail, there is no guarantee on whether this value will be accepted or not ultimately. Paxos guarantees that we'll agree on a value (for a given round in our case), but does not guarantee that the proposer of the agreed upon value will know it. In particular, if for a given proposal at least one accepter has accepted it but not a quorum does, then that value might (but that's not guaranteed either) be replayed (and committed) by another proposer. Currently, if a proposer A proposes some update U but it is rejected, A will sleep a bit and retry U. But if U was accepted by at least one acceptor, some other proposer B might replay U, succeed and commit it. If A does its retry after that happens, he will prepare, check the condition, and probably find that the conditions don't apply anymore since U has been committed already. It will thus return false, even though U has been in fact committed. Unfortunately I'm not sure there is an easy way for a proposer whose propose fails to know if the update will prevail or not eventually. Which mean the only acceptable solution I can see would be to return to the user I don't know (through some exception for instance). Which is annoying because having a proposal rejected won't be an extremely rare occurrence, even with relatively light contention, and returning I don't know often is a bit unfriendly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6013) CAS may return false but still commit the insert
[ https://issues.apache.org/jira/browse/CASSANDRA-6013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-6013: Attachment: 6013-v4.patch I don't follow. getSuccessful/getAcceptCount is supposed to returned how many successful accepts we got. So that's how much time we decremented remainingRequired, i.e. its initial value (requiredTargets) minus it's current value. Similarly, in isFullyRefused, we want to validate that remainingRequired was never decremented (no-one accepted), so we want to compare it's current value with its initial value, requiredTargets (comparing to totalTargets will in fact always fail). I guess the code is more straightforward if we keep the number of accepts instead of the number of remaining accept: attaching v4 with that version (which is equivalent to v2, but with the updated comment of v3). CAS may return false but still commit the insert Key: CASSANDRA-6013 URL: https://issues.apache.org/jira/browse/CASSANDRA-6013 Project: Cassandra Issue Type: Bug Reporter: Sylvain Lebresne Assignee: Jonathan Ellis Fix For: 2.0.1 Attachments: 6013.txt, 6013-v2.txt, 6013-v3.txt, 6013-v4.patch If a Paxos proposer proposes some value/update and that propose fail, there is no guarantee on whether this value will be accepted or not ultimately. Paxos guarantees that we'll agree on a value (for a given round in our case), but does not guarantee that the proposer of the agreed upon value will know it. In particular, if for a given proposal at least one accepter has accepted it but not a quorum does, then that value might (but that's not guaranteed either) be replayed (and committed) by another proposer. Currently, if a proposer A proposes some update U but it is rejected, A will sleep a bit and retry U. But if U was accepted by at least one acceptor, some other proposer B might replay U, succeed and commit it. If A does its retry after that happens, he will prepare, check the condition, and probably find that the conditions don't apply anymore since U has been committed already. It will thus return false, even though U has been in fact committed. Unfortunately I'm not sure there is an easy way for a proposer whose propose fails to know if the update will prevail or not eventually. Which mean the only acceptable solution I can see would be to return to the user I don't know (through some exception for instance). Which is annoying because having a proposal rejected won't be an extremely rare occurrence, even with relatively light contention, and returning I don't know often is a bit unfriendly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6013) CAS may return false but still commit the insert
[ https://issues.apache.org/jira/browse/CASSANDRA-6013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6013: -- Attachment: 6013.txt CAS may return false but still commit the insert Key: CASSANDRA-6013 URL: https://issues.apache.org/jira/browse/CASSANDRA-6013 Project: Cassandra Issue Type: Bug Reporter: Sylvain Lebresne Assignee: Jonathan Ellis Attachments: 6013.txt If a Paxos proposer proposes some value/update and that propose fail, there is no guarantee on whether this value will be accepted or not ultimately. Paxos guarantees that we'll agree on a value (for a given round in our case), but does not guarantee that the proposer of the agreed upon value will know it. In particular, if for a given proposal at least one accepter has accepted it but not a quorum does, then that value might (but that's not guaranteed either) be replayed (and committed) by another proposer. Currently, if a proposer A proposes some update U but it is rejected, A will sleep a bit and retry U. But if U was accepted by at least one acceptor, some other proposer B might replay U, succeed and commit it. If A does its retry after that happens, he will prepare, check the condition, and probably find that the conditions don't apply anymore since U has been committed already. It will thus return false, even though U has been in fact committed. Unfortunately I'm not sure there is an easy way for a proposer whose propose fails to know if the update will prevail or not eventually. Which mean the only acceptable solution I can see would be to return to the user I don't know (through some exception for instance). Which is annoying because having a proposal rejected won't be an extremely rare occurrence, even with relatively light contention, and returning I don't know often is a bit unfriendly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6013) CAS may return false but still commit the insert
[ https://issues.apache.org/jira/browse/CASSANDRA-6013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-6013: Attachment: 6013-v2.txt Unfortunately, I think this is a little grimmer than that. The problem is that a proposer shouldn't move on unless the propose was successful (in which case it returns to the client) or it is sure that the propose will *not* be replayed (if it is sure of that, then retrying the proposed value with a newer ballot is safe; the current problem is that we retry with a newer ballot when we're not sure of that). In other words, we should timeout unless we are either successful or all nodes have answered and none have accepted. I'm attaching a v2 doing that (but still tries to timeout as little as possible without compromising correctness). Unfortunately, this mean we'll timeout as soon as a proposer gets a propose reject but at least one acceptor had accepted it, which is not an extremely rare condition even with moderate contention. That being said, the current behavior is plain wrong, so unless someone has a much better idea that is easy to implement, we should probably go ahead with this for now. CAS may return false but still commit the insert Key: CASSANDRA-6013 URL: https://issues.apache.org/jira/browse/CASSANDRA-6013 Project: Cassandra Issue Type: Bug Reporter: Sylvain Lebresne Assignee: Jonathan Ellis Attachments: 6013.txt, 6013-v2.txt If a Paxos proposer proposes some value/update and that propose fail, there is no guarantee on whether this value will be accepted or not ultimately. Paxos guarantees that we'll agree on a value (for a given round in our case), but does not guarantee that the proposer of the agreed upon value will know it. In particular, if for a given proposal at least one accepter has accepted it but not a quorum does, then that value might (but that's not guaranteed either) be replayed (and committed) by another proposer. Currently, if a proposer A proposes some update U but it is rejected, A will sleep a bit and retry U. But if U was accepted by at least one acceptor, some other proposer B might replay U, succeed and commit it. If A does its retry after that happens, he will prepare, check the condition, and probably find that the conditions don't apply anymore since U has been committed already. It will thus return false, even though U has been in fact committed. Unfortunately I'm not sure there is an easy way for a proposer whose propose fails to know if the update will prevail or not eventually. Which mean the only acceptable solution I can see would be to return to the user I don't know (through some exception for instance). Which is annoying because having a proposal rejected won't be an extremely rare occurrence, even with relatively light contention, and returning I don't know often is a bit unfriendly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6013) CAS may return false but still commit the insert
[ https://issues.apache.org/jira/browse/CASSANDRA-6013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-6013: Fix Version/s: 2.0.1 CAS may return false but still commit the insert Key: CASSANDRA-6013 URL: https://issues.apache.org/jira/browse/CASSANDRA-6013 Project: Cassandra Issue Type: Bug Reporter: Sylvain Lebresne Assignee: Jonathan Ellis Fix For: 2.0.1 Attachments: 6013.txt, 6013-v2.txt If a Paxos proposer proposes some value/update and that propose fail, there is no guarantee on whether this value will be accepted or not ultimately. Paxos guarantees that we'll agree on a value (for a given round in our case), but does not guarantee that the proposer of the agreed upon value will know it. In particular, if for a given proposal at least one accepter has accepted it but not a quorum does, then that value might (but that's not guaranteed either) be replayed (and committed) by another proposer. Currently, if a proposer A proposes some update U but it is rejected, A will sleep a bit and retry U. But if U was accepted by at least one acceptor, some other proposer B might replay U, succeed and commit it. If A does its retry after that happens, he will prepare, check the condition, and probably find that the conditions don't apply anymore since U has been committed already. It will thus return false, even though U has been in fact committed. Unfortunately I'm not sure there is an easy way for a proposer whose propose fails to know if the update will prevail or not eventually. Which mean the only acceptable solution I can see would be to return to the user I don't know (through some exception for instance). Which is annoying because having a proposal rejected won't be an extremely rare occurrence, even with relatively light contention, and returning I don't know often is a bit unfriendly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6013) CAS may return false but still commit the insert
[ https://issues.apache.org/jira/browse/CASSANDRA-6013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6013: -- Description: If a Paxos proposer proposes some value/update and that propose fail, there is no guarantee on whether this value will be accepted or not ultimately. Paxos guarantees that we'll agree on a value (for a given round in our case), but does not guarantee that the proposer of the agreed upon value will know it. In particular, if for a given proposal at least one accepter has accepted it but not a quorum does, then that value might (but that's not guaranteed either) be replayed (and committed) by another proposer. Currently, if a proposer A proposes some update U but it is rejected, A will sleep a bit and retry U. But if U was accepted by at least one acceptor, some other proposer B might replay U, succeed and commit it. If A does its retry after that happens, he will prepare, check the condition, and probably find that the conditions don't apply anymore since U has been committed already. It will thus return false, even though U has been in fact committed. Unfortunately I'm not sure there is an easy way for a proposer whose propose fails to know if the update will prevail or not eventually. Which mean the only acceptable solution I can see would be to return to the user I don't know (through some exception for instance). Which is annoying because having a proposal rejected won't be an extremely rare occurrence, even with relatively light contention, and returning I don't know often is a bit unfriendly. was: If a Paxos proposer proposes some value/update and that propose fail, there is no guarantee on whether this value will be accepted or not ultimately. Paxos only guarantees that we'll agree on a value (for a given round in our case), but does guarantee that the proposer of the agreed upon value will know it. In particular, if for a given proposal at least one accepter has accepted it but not a quorum does, then that value might (but that's not guaranteed either) be replayed (and committed) by another proposer. Currently, if a proposer A proposes some update U but it is rejected, A will sleep a bit and retry U. But if U was accepted by at least one acceptor, some other proposer B might replay U, succeed and commit it. If A does its retry after that happens, he will prepare, check the condition, and probably find that the conditions don't apply anymore since U has been committed already. It will thus return false, even though U has been in fact committed. Unfortunately I'm not sure there is an easy way for a proposer whose propose fails to know if the update will prevail or not eventually. Which mean the only acceptable solution I can see would be to return to the user I don't know (through some exception for instance). Which is annoying because having a proposal rejected won't be an extremely rare occurrence, even with relatively light contention, and returning I don't know often is a bit unfriendly. CAS may return false but still commit the insert Key: CASSANDRA-6013 URL: https://issues.apache.org/jira/browse/CASSANDRA-6013 Project: Cassandra Issue Type: Bug Reporter: Sylvain Lebresne If a Paxos proposer proposes some value/update and that propose fail, there is no guarantee on whether this value will be accepted or not ultimately. Paxos guarantees that we'll agree on a value (for a given round in our case), but does not guarantee that the proposer of the agreed upon value will know it. In particular, if for a given proposal at least one accepter has accepted it but not a quorum does, then that value might (but that's not guaranteed either) be replayed (and committed) by another proposer. Currently, if a proposer A proposes some update U but it is rejected, A will sleep a bit and retry U. But if U was accepted by at least one acceptor, some other proposer B might replay U, succeed and commit it. If A does its retry after that happens, he will prepare, check the condition, and probably find that the conditions don't apply anymore since U has been committed already. It will thus return false, even though U has been in fact committed. Unfortunately I'm not sure there is an easy way for a proposer whose propose fails to know if the update will prevail or not eventually. Which mean the only acceptable solution I can see would be to return to the user I don't know (through some exception for instance). Which is annoying because having a proposal rejected won't be an extremely rare occurrence, even with relatively light contention, and returning I don't know often is a bit unfriendly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please
