cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1072) Increment counters
Date Thu, 24 Jun 2010 12:49:53 GMT

    [ 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.


Mime
View raw message