Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: zookeeper-user@hadoop.apache.org
Received-SPF: neutral (nike.apache.org: 216.145.54.173 is neither permitted
 nor denied by domain of phunt@apache.org)
Message-ID: <4AC4F14B.5080107@apache.org>
Date: Thu, 01 Oct 2009 11:13:31 -0700
From: Patrick Hunt <phunt@apache.org>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: zookeeper-user@hadoop.apache.org
CC: Stefan Groschupf <sg@101tec.com>,
        "zookeeper-dev@hadoop.apache.org" <zookeeper-dev@hadoop.apache.org>
Subject: Re: feedback zkclient
References: <CDA88AE0-D60C-4DB4-89DD-B40DFF677B1B@101tec.com>
 	<4AC3D75F.4080300@apache.org> <4AC452EF.5010405@apache.org>
 	<B7301E5B-F233-4E1E-BBC0-A33EB7F40AB8@petervoss.org>
 <c7d45fc70910010922u7956abedu4eb3e751acf17f41@mail.gmail.com>
In-Reply-To: <c7d45fc70910010922u7956abedu4eb3e751acf17f41@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Ted Dunning wrote:
> 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.

One nice thing about ephemeral is that the Stat contains the owner 
sessionid. As you say, it's highly implementation dependent. It's also 
something we recognize is a problem for users, we've slated it for 3.3.0
http://issues.apache.org/jira/browse/ZOOKEEPER-22

Patrick


> 
> 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?
> 
> 
> 
>