cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Darcy (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-1072) Increment counters
Date Mon, 16 Aug 2010 18:19:23 GMT


Jeff Darcy commented on CASSANDRA-1072:

Sylvain, what does "wait for a number of acks" in your/Kelvin's step 4 mean? What happens
if one or more replicas are on the other side of a partition? What values are returned while
the chosen replica is waiting for acks? It's all very well to make a "good faith" attempt
to reduce the window of inconsistency by sending updates to other replicas early, but waiting
indefinitely seems like trying to enforce strong consistency and if the wait terminates then
we have to handle the repair after the partition is resolved anyway. This may be the same
objection as Jonathan made at 8pm on August 10, although it covers more cases than just multi-DC
because partitions can and do occur within DCs as well. Reading the current version vector
as part of a write doesn't seem like enough of a problem to justify complex workarounds, since
it's probably in memory anyway (especially for a hot counter).

> Increment counters
> ------------------
>                 Key: CASSANDRA-1072
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Johan Oskarsson
>            Assignee: Kelvin Kakugawa
>         Attachments: CASSANDRA-1072-2.patch, CASSANDRA-1072.patch, Incrementcountersdesigndoc.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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message