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 95C808282 for ; Tue, 30 Aug 2011 17:31:31 +0000 (UTC) Received: (qmail 86595 invoked by uid 500); 30 Aug 2011 17:31:29 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 86510 invoked by uid 500); 30 Aug 2011 17:31:28 -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 86502 invoked by uid 99); 30 Aug 2011 17:31:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Aug 2011 17:31:28 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jiangc@gmail.com designates 209.85.212.44 as permitted sender) Received: from [209.85.212.44] (HELO mail-vw0-f44.google.com) (209.85.212.44) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Aug 2011 17:31:23 +0000 Received: by vws12 with SMTP id 12so3712877vws.31 for ; Tue, 30 Aug 2011 10:31:02 -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=BtI6e8roC9iIoLjHooNA1K08gh1b9ZSajhNSQFW14qY=; b=QqdlkM4rHePK6TpEAAiSH7YPvVsgMDTtGRChw/yNVtgMaBDAbyFQvUeYyNm01lMu02 2ClwwOpKajvciMc1SMMMTG3WpxXa6XciLKc71O9qCiaefqVtC/tL5zGp78+NGdMXSj6b +bxuUIYDjdNy2NH3Aye3DHAgDVbs55QJwDnr0= MIME-Version: 1.0 Received: by 10.52.21.139 with SMTP id v11mr4381919vde.329.1314725462214; Tue, 30 Aug 2011 10:31:02 -0700 (PDT) Received: by 10.52.115.228 with HTTP; Tue, 30 Aug 2011 10:31:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Aug 2011 13:31:02 -0400 Message-ID: Subject: Re: Updates lost From: Jiang Chen To: user@cassandra.apache.org Content-Type: text/plain; charset=ISO-8859-1 Looks like the theory is correct for the java case at least. The default timestamp precision of Pelops is millisecond. Hence the problem as explained by Peter. Once I supplied timestamps precise to microsecond (using System.nanoTime()), the problem went away. I previously stated that sleeping for a few milliseconds didn't help. It was actually because of the precision of Java Thread.sleep(). Sleeping for less than 15ms often doesn't sleep at all. Haven't checked the Python side to see if it's similar situation. Cheers. Jiang On Tue, Aug 30, 2011 at 9:57 AM, Jiang Chen wrote: > It's a single node. Thanks for the theory. I suspect part of it may > still be right. Will dig more. > > On Tue, Aug 30, 2011 at 9:50 AM, Peter Schuller > wrote: >>> The problem still happens with very high probability even when it >>> pauses for 5 milliseconds at every loop. If Pycassa uses microseconds >>> it can't be the cause. Also I have the same problem with a Java client >>> using Pelops. >> >> You connect to localhost, but is that a single node or part of a >> cluster with RF > 1? If the latter, you need to use QUORUM consistency >> level to ensure that a read sees your write. >> >> If it's a single node and not a pycassa / client issue, I don't know off hand. >> >> -- >> / Peter Schuller (@scode on twitter) >> >