cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajath Subramanyam <rajat...@gmail.com>
Subject Re: Partitioned Counters Design
Date Fri, 10 Oct 2014 08:44:39 GMT
Hi Aleksey,

Thanks for the response. I read through several JIRAs ( CASSANDRA-1072,
CASSANDRA-2495, CASSANDRA-4775, CASSANDRA-6504, CASSANDRA-6506). I would
appreciate if you can clarify my understanding of the current state of art.

I understand that the earlier design of having local shards, remote shards
and logging only deltas for local shards provided good latency but suffered
inconsistencies due to replays not being idempotent. Was this primarily
lack of internal idempotent updates (replica-replica) or due to lack
external idempotent updates (client-coordinator) ? Also, I have an
additional question about the state of counters before CASSANDRA-6504 (or
Counters 1.0 if you like). Does the client submit
CounterUpdate<counter-name, value, timestamp> ? During the retry is the
same  CounterUpdate<counter-name, value, timestamp> submitted again
identically as the original attempt ? When the coordinator (if it is one of
the replica) OR the leader does a write propagation to the other replicas
does it include the same CounterUpdate<counter-name, value, timestamp> ?
Essentially, my question is: Can we identify each counter update from a
client uniquely ? and does the retry use the same unique id ?

Also post the implementation of CASSANDRA-6504 (or Counters 2.0 design) I
understand that local and remote shards have been replaced by global shards
and now counters follow a lock-read-write-unlock-replicate model. Does this
guarantee that retries from clients are still idempotent ? Also, in
Counters 2.0, is the CounterUpdate sent by the client an unique id ?

I would appreciate your clarification on this.

Thank you !

Regards,
Rajath


------------------------
Rajath Subramanyam


On Mon, Oct 6, 2014 at 3:38 PM, Aleksey Yeschenko <aleksey@apache.org>
wrote:

> No, there are no unique ids per increment. That was one of the ideas
> suggested in https://issues.apache.org/jira/browse/CASSANDRA-4775, but
> ultimately declined.
>
> Read that ticket, and the one linked to it, for details.
>
> --
> AY
>
> On October 6, 2014 at 10:20:05 PM, Rajath Subramanyam (rajath26@gmail.com)
> wrote:
>
> Hi Cassandra developers,
>
> I am working on a project to make counter updates idempotent. I read that
> via CASSANDRA-1546 assigns unique marker ids to counter updates in 0.7.1.
> Does this unique marker id hold true in the later versions too ? Or at
> least in 0.8.1 ?
>
> Please let me know.
>
> Thank you !
>
> Regards,
> Rajath
> ------------------------
> Rajath Subramanyam
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message