[
https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882144#action_12882144
]
Sylvain Lebresne commented on CASSANDRA-1072:
---------------------------------------------
{quote}
Handling CL > ONE:
My thoughts would be to send a write to multiple nodes (but, still, for one
node id). And, have a node (that's not responsible for that node id) still
aggregate the counts it has for the given node id. i.e. it would still help
nodes "catch up" to that node id's total count. The big caveat would be that
the initial write path would need to be special-cased.
{quote}
I realize now that it can be a bit tricky. I agree that we would kind of want
that nodes always aggregate the counts it has for all id (or did I
misunderstand what you're suggesting ?), as otherwise you'll fairly rarely get
the more up to date version for a counter without CL.ALL (or am I missing
something ?). For the 'the initial write path would need to be special-cased',
couldn't that be dealt using the context ? From what I understand, what we
want is to differentiate between initial update coming from the client (that
can be added to our previously known count) and update that comes for conflict
resolution (read repairs and such, where we want to keep the more up to date
value). Maybe a 'freshness' flag could be added to the context header, that
would be initially to true and switch to false by any resolution. Is that
completely stupid ?
In any case, if we sent the write to multiple nodes, shouldn't we ensure that
the node responsible for the write did get it ? Seems to me the algorithm rely
on the fact that each node have the right count for it's count id.
Not sure I see very clearly yet in all that (But I'm willing to see the light
:)).
{quote}
RRR.resolveSuperset():
As you suspected, it's not an efficiency-motivated modification. If cloneMe()
is used, there's the potential to aggregate a given node id's counts an extra
time (from that initial cloneMe() call).
{quote}
Very true.
> Increment counters
> ------------------
>
> Key: CASSANDRA-1072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1072
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Johan Oskarsson
> Assignee: Kelvin Kakugawa
> Attachments: CASSANDRA-1072-2.patch, CASSANDRA-1072.patch
>
>
> 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 manageable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
