Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (nike.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.212.42 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=Bjj7ZSKeeBGNIGRDiBkqjxUUi6bnxmvqduInU8pIcAICc6PNAit/6g+ygBFp/m03Uk
         BUfPlb7btUr32H0Vv83MBSdXUhfDWLN3OY8BGt+A7Wnv2NAjx4mjbYzd/WQs95XSTwxP
         VRcC/mWmwchrtdNu2cytEAZZNCh/SE1VZZJF0=
MIME-Version: 1.0
In-Reply-To: <4D35D4F4.8060103@yahoo-inc.com>
References: <AANLkTi=hUr1qbJbupwxeE=OAeX5w1mVVJ+nHMaMRVbM5@mail.gmail.com>
 <AANLkTinBUffzGORT5hOSSiuLCmZqY8gXnzJBy2TnZ9mi@mail.gmail.com>
 <4D35D4F4.8060103@yahoo-inc.com>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Tue, 18 Jan 2011 09:11:38 -0800
Message-ID: <AANLkTinBTxx7J4NzFtZ5XipahKEUonz=FwxcjOcT_rvw@mail.gmail.com>
Subject: Re: Atomic Compare-and-swap like operations
To: user@zookeeper.apache.org
Content-Type: multipart/alternative; boundary=0016364ef32083be75049a21ff84

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

Regarding multi,

I have the request and responses all set up on the client and server side
and have a test that sends a multi request to the server.

The server falls over at that point (of course) because it doesn't know how
to handle that request type.

My problem at this point is that there isn't much of a roadmap for where the
response actually needs to be handled.  Right now my test fails pretty late
in the processing because the response header is never set up.  Can somebody
point me to the classes that actually need to handle the multi request?

(for the non-insiders, the confusion arises because of the way the server is
modularized.  Steps in the processing are arranged in a pipeline, each of
which handles one distinct aspect of the process.  These steps are arranged
differently on a slave, on the master and on a stand-alone server.  Having
the steps arranged differently allows the steps to be re-used for these
different kinds of server.  That does make changing the server a bit more
complex, though since some steps forward some request but not others and
other steps handle some requests and not others.  Finding all the places to
change can be tricky to do right if you don't know the code.  I don't know
the code)

On Tue, Jan 18, 2011 at 9:59 AM, Benjamin Reed <breed@yahoo-inc.com> wrote:

> it would be nice if it could be folded in, it does create a problem though.
> the issue is that only reads do not go through the atomic broadcast, so in
> some recovery cases it would be hard to get the old data back. it's not that
> in can't be done, but i think it significantly complicates the design.
>
> it seems like the easiest way to do this would be to have the
> delete-and-return operation so that the old data is explicitly put in the
> recovery log. if we do delete-and-return, we probably also want
> set-and-return :)
>
> ben
>
>
> On 01/15/2011 01:43 PM, Ted Dunning wrote:
>
>> I think that the multi stuff is the ideal place for this kind of
>> capability.
>>  To do this, we would need to add a get operation to the current
>> collection.
>>  I think that would be an excellent addition, not only for your use case
>> but
>> also the one where you want to get consistent copies of several znodes at
>> once.
>>
>> On Sat, Jan 15, 2011 at 8:14 AM, Scott Fines<scottfines@gmail.com>
>>  wrote:
>>
>>  It seems like it would be a very powerful option to be able to have a
>>> "delete-and-return" operation that atomically deletes a znode, and
>>> returns
>>> the bytes that were previously stored in that znode. Is there a
>>> particular
>>> reason why this was not chosen as the behavior of the API? In most of the
>>> other generic compare-and-swap operations (put-if-absent and
>>> set-if-matches), there is already a mechanism in place, or one can
>>> relatively easily be implemented, but this seems like an odd oversight.
>>>
>>> I saw that ZooKeeper-965<
>>> https://issues.apache.org/jira/browse/ZOOKEEPER-965>
>>> could
>>> potentially address this in the future, but it seems like API overkill
>>> for
>>> something like this.
>>>
>>>
>

--0016364ef32083be75049a21ff84--