cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <>
Subject Re: Counter consistency - are counters idempotent?
Date Fri, 22 Jul 2011 16:19:38 GMT
If that's the case, your client is being misleading.  Cassandra
distinguishes between Unavailable (we knew we couldn't achieve CL
before we started, and nothing changed) and TimedOut (didn't get reply
in a timely fashion; it may or may not have gone through).

TimedOut != Failed.

On Fri, Jul 22, 2011 at 11:08 AM, Yang <> wrote:
> btw, this "issue" of  not knowing whether a write is persisted or not
> when client reports error, is not limited to counters,  for regular
> columns, it's the same: if client reports write failure, the value may
> well be replicated to all replicas later.  this is even the same with
> all other systems: Zookeeper, Paxos, ultimately due to the FLP
> theoretical result of "no guarantee of consensus in async systems"
> ---------- Forwarded message ----------
> From: Sylvain Lebresne <>
> Date: Fri, Jul 22, 2011 at 8:03 AM
> Subject: Re: Counter consistency - are counters idempotent?
> To:
> On Fri, Jul 22, 2011 at 4:52 PM, Kenny Yu <> wrote:
>> As of Cassandra 0.8.1, are counter increments and decrements idempotent? If,
>> for example, a client sends an increment request and the increment occurs,
>> but the network subsequently fails and reports a failure to the client, will
>> Cassandra retry the increment (thus leading to an overcount and inconsistent
>> data)?
>> I have done some reading and I am getting conflicting sources about counter
>> consistency. In this source
>> (,
>> it states that counters now have the same consistency as regular
>> columns--does this imply that the above example will not lead to an
>> overcount?
> That email thread was arguably a bit imprecise with its use of the
> word 'consistency'
> but what it was talking about is really consistency level. That is, counter
> supports all the usual consistency levels (ONE, QUORUM, ALL, LOCAL_QUORUM,
> EACH_QUORUM) excepted ANY.
> Counter are still not idempotent. And just a small precision, if you
> get a TimeoutException,
> Cassandra never retry the increment on it's own (your sentence
> suggests it does),
> but you won't know in that case if the increment was persisted or not,
> and thus you
> won't know if you should retry or not. And yes, this is still a
> limitation of counters.
>> If counters are not idempotent, are there examples of effective uses of
>> counters that will prevent inconsistent counts?
>> Thank you for your help.

Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support

View raw message