[
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
