Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: zookeeper-user@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of ted.dunning@gmail.com
 designates 74.125.82.48 as permitted sender)
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
         :content-type;
        b=lyf9nSZXgMonPC/iBWuI4BEpHd0T191xOz7lgaBoMfjBNkBRihYvVG3gjQwK+fHJqL
         C8FOwnL2To3XnPZs1kH2a2aFWhGyIHYXFdRQ3Jk1OejegnaBg1kAx8TWTYIBGucPvJko
         oaAXU9oSUT2yp8Pz/npRIQAU9FbZlfAgKK+Gc=
MIME-Version: 1.0
In-Reply-To: <AANLkTik=jj0MFE3SFo1HLygM8NJXiWrFvfjWegyj9oXm@mail.gmail.com>
References: <AANLkTin+r69k9wbt6VwP+txNw2Yhf_YAsiXN07SwuKr9@mail.gmail.com>
 <AANLkTikJfPsWOjhhamuM8UciqzcDtOrH_eHuBdYK-1No@mail.gmail.com>
 <AANLkTi=wkYtLxqFeyY6LzaGB0dMRJFf1ACqW_=+YCtvH@mail.gmail.com>
 <AANLkTik+rEwUEO0UdGd34m=qVQ59VQXV11opKpBi3kUT@mail.gmail.com>
 <AANLkTikkOtxeLYGzRRM6n_0TM_uXpbHa4n14AJxdmjuS@mail.gmail.com>
 <AANLkTik=jj0MFE3SFo1HLygM8NJXiWrFvfjWegyj9oXm@mail.gmail.com>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Wed, 20 Oct 2010 15:27:57 -0700
Message-ID: <AANLkTikkOtYODZ-+kqaiCiJ+5bAeHFTxGBaqF2Q4SPf2@mail.gmail.com>
Subject: Re: Retrying sequential znode creation
To: zookeeper-user@hadoop.apache.org
Content-Type: multipart/alternative; boundary=0016364d26cf0fcae7049313ed04

--0016364d26cf0fcae7049313ed04
Content-Type: text/plain; charset=UTF-8

These corner cases are relatively rare, I would think (I personally keep
logs around for days or longer).

Would it be possible to get a partial solution in place that invokes the
current behavior if logs aren't available?

On Wed, Oct 20, 2010 at 10:42 AM, Patrick Hunt <phunt1@gmail.com> wrote:

> Hi Ted, Mahadev is in the best position to comment (he looked at it last)
> but iirc when we started looking into implementing this we immediately ran
> into so big questions. One was what to do if the logs had been cleaned up
> and the individual transactions no longer available. This could be overcome
> by changes wrt cleanup, log rotation, etc... There was another more
> bulletproof option, essentially to keep all the changes in memory that
> might
> be necessary to implement 22, however this might mean a significant
> increase
> in mem requirements and general bookkeeping. It turned out (again correct
> me
> if I'm wrong) that more thought was going to be necessary, esp around
> ensuring correct operation in any/all special cases.
>
> Patrick
>
> On Wed, Oct 13, 2010 at 12:49 PM, Ted Dunning <ted.dunning@gmail.com>
> wrote:
>
> > Patrick,
> >
> > What are these hurdles?  The last comment on ZK-22 was last winter.  Back
> > then, it didn't sound like
> > it was going to be that hard.
> >
> > On Wed, Oct 13, 2010 at 12:08 PM, Patrick Hunt <phunt@apache.org> wrote:
> >
> > > 22 would help with this issue
> > > https://issues.apache.org/jira/browse/ZOOKEEPER-22
> > > however there are some real hurdles to implementing 22 successfully.
> > >
> >
>

--0016364d26cf0fcae7049313ed04--