Return-Path: Delivered-To: apmail-hadoop-zookeeper-user-archive@minotaur.apache.org Received: (qmail 33543 invoked from network); 13 Oct 2010 12:59:29 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 13 Oct 2010 12:59:29 -0000 Received: (qmail 4278 invoked by uid 500); 13 Oct 2010 12:59:29 -0000 Delivered-To: apmail-hadoop-zookeeper-user-archive@hadoop.apache.org Received: (qmail 4154 invoked by uid 500); 13 Oct 2010 12:59:26 -0000 Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: zookeeper-user@hadoop.apache.org Delivered-To: mailing list zookeeper-user@hadoop.apache.org Received: (qmail 4146 invoked by uid 99); 13 Oct 2010 12:59:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Oct 2010 12:59:26 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of vishalmlst@gmail.com designates 209.85.215.48 as permitted sender) Received: from [209.85.215.48] (HELO mail-ew0-f48.google.com) (209.85.215.48) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Oct 2010 12:59:18 +0000 Received: by ewy28 with SMTP id 28so1882703ewy.35 for ; Wed, 13 Oct 2010 05:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=ise5aXz3q3U9LeTRbqWLI7t2UkVuC5aOBfefSG++4CI=; b=yIWS2VBu67bnNLuEd66m4zj4w1eqZ05s92VGQhnd+EvPSDs+Cm5ho5SUYlzkJDeCpv 6rKNr4ILRyemmt7POjH2GRysdOcgTl3RXRs7SX7/gr95k42PErqoQ+KPtRu2Q+ypGKbH anYP4A0zZPmtEbFLZS8HJajGzn5N/8snrzI1A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=uTXZdGzPEJy8hj0vSKcSzgpO35vghv2vrwVuHjxJvNsfEmiLkEsdoVmo97yVpftcFQ QQDxlg3hM5GAY6heqMyJesUnzlAHZCHXgx8TgXwwvdROJ02WmrVVThGRttffEoKHPqHn PDldaF76BUxYIkxidut7PK/efr8A1aL1UH69A= MIME-Version: 1.0 Received: by 10.213.2.133 with SMTP id 5mr472653ebj.86.1286974737695; Wed, 13 Oct 2010 05:58:57 -0700 (PDT) Received: by 10.14.37.10 with HTTP; Wed, 13 Oct 2010 05:58:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Oct 2010 08:58:57 -0400 Message-ID: Subject: Re: Retrying sequential znode creation From: Vishal K To: zookeeper-user@hadoop.apache.org Content-Type: multipart/alternative; boundary=0015174be06413447104927f28fe X-Virus-Checked: Checked by ClamAV on apache.org --0015174be06413447104927f28fe Content-Type: text/plain; charset=ISO-8859-1 Hi Ted, Thanks for the reply. I prefer to store the UUID in the data itself. I thought about storing it in znode names, but the downside of this approach is that when a Watcher receives an event, it needs to strip off the UUID. Otherwise, it wont be possible to figure out the order znodes (e.g., using sort()). Also, in our case, there are very few sequential children. So listing and reading all children is not a big overhead. However, gets trickier because there is no explicit way (to my knowledge) to get CreateMode for a znode. As a result, we cannot tell whether a node is sequential or not. Thanks. -Vishal On Tue, Oct 12, 2010 at 5:36 PM, Ted Dunning wrote: > Yes. This is indeed a problem. I generally try to avoid sequential nodes > unless they are ephemeral and if I get an error on > creation, I generally have to either tear down the connection (losing all > other ephemeral nodes in the process) or scan through > all live nodes trying to determine if mine got created. Neither is a very > acceptable answer so I try to avoid the problem. > > Your UUID answer is one option. At least you know what file got created > (or > not) and with good naming you can pretty much guarantee no collisions. You > don't have to scan all children since you can simply check for the > existence > of the file of interest. > > There was a JIRA filed that was supposed to take care of this problem, but > I > don't know the state of play there. > > On Tue, Oct 12, 2010 at 12:11 PM, Vishal K wrote: > > > Hi, > > > > What is the best approach to have an idempotent create() operation for a > > sequential node? > > > > Suppose a client is trying to create a sequential node and it gets a > > ConnectionLoss KeeperException, it cannot know for sure whether the > request > > succeeded or not. If in the meantime, the client's session is > > re-established, the client would like to create a sequential znode again. > > However, the client needs to know if its earlier request has succeeded or > > not. If it did, then the client does not need to retry. To my > understanding > > ZooKeeper does not provide this feature. Can someone confirm this? > > > > External to ZooKeeper, the client can either set a unique UUID in the > path > > to the create call or write the UUID as part of its data. Before > retrying, > > it can read back all the children of the parent znode and go through the > > list to determine if its earlier request had succeeded. This doesn't > sound > > that appealing to me. > > > > I am guessing this is a common problem that many would have faced. Can > > folks > > give a feedback on what their approach was? > > > > Thanks. > > -Vishal > > > --0015174be06413447104927f28fe--