[
https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12964568#action_12964568
]
Sylvain Lebresne commented on CASSANDRA-1072:
---------------------------------------------
I read through the last patch:
# I think there is a "bug" with the repair-on-write. As written, before
sending a "repair", it cleans the context for all the replicas it will send it
to, that is all alive replicas. This will basically clean up everything (except
for maybe the count of down or old (decommissioned) replicas). Again, unless
I'm missing something obvious, this will basically spend its time sending empty
row mutations. For each replica, only the context of this replica should be
cleaned before sending it the repair mutation for this to be useful.
# Even if "fixed", repair-on-write doesn't help to give consistency
guarantees, being (non-optionally) asynchronous. Only CL.ONE is supported for
writes (which anecdotally is only checked by an assertion much too late). I
see no reason for that limitation and to me it sure sound like something we
want to provide on day one.
# It removes the fix of the race condition. I strongly believe correctness
should be our first concern. Making the race condition less harmful is not a
fix. That being said, I'm not saying the fix in 1546 cannot be improved and the
locking be made more fine-grained.
Even in the absence of any failure, there is no more guarantee that what CL.ONE
has to offers. By giving so little guarantees, 1072 will make the counter
useful to much less people that it could, and this for no clear reason.
> Increment counters
> ------------------
>
> Key: CASSANDRA-1072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1072
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Johan Oskarsson
> Assignee: Kelvin Kakugawa
> Attachments: CASSANDRA-1072.112210.patch, CASSANDRA-1072.patch,
> increment_test.py, Partitionedcountersdesigndoc.pdf
>
>
> Break out the increment counters out of CASSANDRA-580. Classes are shared
> between the two features but without the plain version vector code the
> changeset becomes smaller and more manageable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
