cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4775) Counters 2.0
Date Wed, 12 Jun 2013 18:40:20 GMT


Jonathan Ellis commented on CASSANDRA-4775:

bq. We could change that "implementation detail". Instead we could stop distinguishing the
merge rules for local shard, and when a replica need to increment his hard, he would read/increment/write
while holding a lock to ensure atomicity. This would likely simplify the implementation and
fix CASSANDRA-4071 and CASSANDRA-4417. Of course, this would still not fix the other top-level
problems (not being able to replay, broken remove, ....).

I'm starting to think this is probably our lowest-hanging fruit here.  I think we could get
good performance too if we "cache" hot counters as AtomicLong objects.

I note for the record that "retryable" is at the very bottom of my priorities here.  Single-machine
databases don't allow retry either if they lose the connection in the middle of {{UPDATE foo
SET x=x+1 WHERE key = ...}}.  And everyone just lives with it.
> Counters 2.0
> ------------
>                 Key: CASSANDRA-4775
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Arya Goudarzi
>            Assignee: Aleksey Yeschenko
>              Labels: counters
>             Fix For: 2.1
> The existing partitioned counters remain a source of frustration for most users almost
two years after being introduced.  The remaining problems are inherent in the design, not
something that can be fixed given enough time/eyeballs.
> Ideally a solution would give us
> - similar performance
> - less special cases in the code
> - potential for a retry mechanism

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:

View raw message