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 <teddyyyy...@gmail.com> 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 <sylv...@datastax.com> > Date: Fri, Jul 22, 2011 at 8:03 AM > Subject: Re: Counter consistency - are counters idempotent? > To: user@cassandra.apache.org > > > On Fri, Jul 22, 2011 at 4:52 PM, Kenny Yu <kenny...@knewton.com> 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 >> (http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/clarification-of-the-consistency-guarantees-of-Counters-td6421010.html), >> 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 http://www.datastax.com
