[
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
