Return-Path: 
 <zookeeper-user-return-928-apmail-hadoop-zookeeper-user-archive=hadoop.apache.org@hadoop.apache.org>
Delivered-To: apmail-hadoop-zookeeper-user-archive@minotaur.apache.org
Received: (qmail 49496 invoked from network); 1 Oct 2009 16:24:45 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 1 Oct 2009 16:24:45 -0000
Received: (qmail 34520 invoked by uid 500); 1 Oct 2009 16:24:45 -0000
Delivered-To: apmail-hadoop-zookeeper-user-archive@hadoop.apache.org
Received: (qmail 34464 invoked by uid 500); 1 Oct 2009 16:24:44 -0000
Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:zookeeper-user-help@hadoop.apache.org>
List-Unsubscribe: <mailto:zookeeper-user-unsubscribe@hadoop.apache.org>
List-Post: <mailto:zookeeper-user@hadoop.apache.org>
List-Id: <zookeeper-user.hadoop.apache.org>
Reply-To: zookeeper-user@hadoop.apache.org
Delivered-To: mailing list zookeeper-user@hadoop.apache.org
Received: (qmail 34445 invoked by uid 99); 1 Oct 2009 16:24:44 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Oct 2009 16:24:44 +0000
X-ASF-Spam-Status: No, hits=2.2 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.216.197 as permitted sender)
Received: from [209.85.216.197] (HELO mail-px0-f197.google.com)
 (209.85.216.197)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Oct 2009 16:24:35 +0000
Received: by pxi35 with SMTP id 35so358947pxi.2
        for <multiple recipients>; Thu, 01 Oct 2009 09:23:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:in-reply-to:references
         :from:date:message-id:subject:to:cc:content-type;
        bh=SHXxjxmDd6TpF8afcqfWUr5Z9swMAeP4oGMWjZuQzjQ=;
        b=sZueQ72lOln2eldYwMX2l1FQB60U8AoKxS4EuQdlO4hLN3PutKhWdCy/Dg1s+9vxLe
         xSprpng4qHHcanKsY/4rU4Qgeb+lhfBN53GiQDDymqHs+osXEL1YoREoe7Q/Nrh3p1/g
         /+zedULRdcRq+sN7RRWhFuAVDCiPyQoNih2W4=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type;
        b=NJBfjzdAmOLIXY5SbOXVs+Q4YiXnGmpUn9jhTMd3g61KYhq/yS4j50oIp9pSFPgSM/
         /hLJBY34F6I/L+h9yfDiKtu+kuYbsIb3VmxCVmT3qCvv7jF3F0ye8qdhITqrL7s4irOc
         SnhZnmDDc9r7rPfug/SB6mzTouWETmyvaAu6c=
MIME-Version: 1.0
Received: by 10.115.132.6 with SMTP id j6mr2386354wan.4.1254414193452;
 Thu, 01
	Oct 2009 09:23:13 -0700 (PDT)
In-Reply-To: <B7301E5B-F233-4E1E-BBC0-A33EB7F40AB8@petervoss.org>
References: <CDA88AE0-D60C-4DB4-89DD-B40DFF677B1B@101tec.com>
	<4AC3D75F.4080300@apache.org> <4AC452EF.5010405@apache.org>
	<B7301E5B-F233-4E1E-BBC0-A33EB7F40AB8@petervoss.org>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Thu, 1 Oct 2009 09:22:53 -0700
Message-ID: <c7d45fc70910010922u7956abedu4eb3e751acf17f41@mail.gmail.com>
Subject: Re: feedback zkclient
To: zookeeper-user@hadoop.apache.org
Cc: Stefan Groschupf <sg@101tec.com>,
	"zookeeper-dev@hadoop.apache.org" <zookeeper-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary=0016e648f37066e9180474e21036
X-Virus-Checked: Checked by ClamAV on apache.org

--0016e648f37066e9180474e21036
Content-Type: text/plain; charset=UTF-8

There is not much way to totally avoid this without massive performance loss
because the connection loss could be during the the time that the
confirmation is returning.

You may be able to tell if the file is yours be examining the content and
ownership, but this is pretty implementation dependent.  In particular, it
makes queues very difficult to implement correctly.  If this happens during
the creation of an ephemeral file, the only option may be to close the
connection (thus deleting all ephemeral files) and start over.

On Thu, Oct 1, 2009 at 8:05 AM, Peter Voss <info@petervoss.org> wrote:

> 3) there's definitely an issue in the retryUntilConnected logic that you
>> need to address
>>
>> let's say you call zkclient.create, and the connection to the server is
>> lost while the request is in flight. At this point ConnectionLoss is thrown
>> on the client side, however you (client) have no information on whether the
>> server has made the change or not. The retry method's while loop will re-run
>> the create (after reconnect), and the result seen by the caller (user code)
>> could be either OK or may be NODEEXISTS exception, there's no way to know
>> which.
>>
>> Mahadev is working on ZOOKEEPER-22 which will address this issue, but
>> that's a future version, not today.
>>
>
> Good catch. I wasn't aware that nodes could still be have been created when
> receiving a ConnectionLoss. But how would you deal with that?
> If we create a znode and get a ConnectionLoss exception, then wait until
> the connection is back and check if the znode is there. There is no way of
> knowing whether it was us who created the node or somebody else, right?




-- 
Ted Dunning, CTO
DeepDyve

--0016e648f37066e9180474e21036--