Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5422B7C8D for ; Fri, 22 Jul 2011 16:08:53 +0000 (UTC) Received: (qmail 73237 invoked by uid 500); 22 Jul 2011 16:08:51 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 73211 invoked by uid 500); 22 Jul 2011 16:08:50 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 73203 invoked by uid 99); 22 Jul 2011 16:08:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jul 2011 16:08:50 +0000 X-ASF-Spam-Status: No, hits=2.3 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HK_RANDOM_ENVFROM,HK_RANDOM_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of teddyyyy123@gmail.com designates 209.85.213.172 as permitted sender) Received: from [209.85.213.172] (HELO mail-yx0-f172.google.com) (209.85.213.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jul 2011 16:08:44 +0000 Received: by yxp4 with SMTP id 4so1587987yxp.31 for ; Fri, 22 Jul 2011 09:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=2lUmkUaAqrk5A1qCCNc0z3VvCpdGk/kGvZJlLC3jW74=; b=sGHnvVwMbswVHW0/quYFT/slZs0xvVeRJS/2v8X/iAY4HFZFLyK+hJG/1zuvCyO7OQ WCKsJMbHgYY6ATOf8al9WKVWbPRUuCASM0GD8vy3bEFa3/0oE7Fuf8O/fPOqevxP9i+R ygNAk5SXjsg8uypLdEVkWmCAQGQJBBgc0GL5g= MIME-Version: 1.0 Received: by 10.236.78.102 with SMTP id f66mr2530875yhe.7.1311350903616; Fri, 22 Jul 2011 09:08:23 -0700 (PDT) Received: by 10.236.61.4 with HTTP; Fri, 22 Jul 2011 09:08:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Jul 2011 09:08:23 -0700 Message-ID: Subject: Fwd: Counter consistency - are counters idempotent? From: Yang To: user@cassandra.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org 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: user@cassandra.apache.org 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 > (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.