You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2013/06/12 20:40:20 UTC

[jira] [Commented] (CASSANDRA-4775) Counters 2.0

    [ https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13681488#comment-13681488 ] 

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: https://issues.apache.org/jira/browse/CASSANDRA-4775
>             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: http://www.atlassian.com/software/jira