[
https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718481#comment-13718481
]
Nicolas Favre-Felix commented on CASSANDRA-4775:
------------------------------------------------
[~jbellis] sorry about the late answer.
I am not convinced that locking before to the commit log entry is a great idea.
First, it does not *solve* the retry problem, even if it does mitigate it
somewhat. It allows batches to be retried internally but doesn't give any
guarantee to the client in the case of a timeout before the batch is added to
the batchlog.
I implemented a read-modify-write (RMW) counter as a personal exercise last
year and gave up on the idea because its performance was much lower than the
current implementation. Cassandra currently allows concurrent updates to the
same counter, with two clients applying deltas +x and +y, resulting in two
replication reads that might both read (+x+y). This is not possible with a
locked RMW and I remember observing many more timeouts on "hot" counters due to
contention on this very coarse lock.
My toy implementation did not even lock around the commit log entry, which
would be even slower.
It is true that the read in a RMW design is cheaper than the current read which
might be touching several SSTables, but it's still very expensive and I'm
worried that the internal retry safety wouldn't be enough to convince users
that these slower counters are "better".
What do you think?
> 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
