zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Create nested paths
Date Thu, 01 Mar 2012 23:25:39 GMT

The only good thing to say here is that, yes, there is a one to one correspondence between
arguments and results in the returned list. 

I will have to check the documentation to see if throwing an exception is the correct thing
to do for check. It surprises me a bit that you are seeing this result. 

Sent from my iPhone

On Mar 1, 2012, at 3:14 PM, "Shelley, Ryan" <Ryan.Shelley@disney.com> wrote:

> Right, I did this:
> (psuedo-code)
> List<Ops> ops
> For(path in paths)
>  ops.add( Op.check(path, -1) )
> EndFor
> List<OpResult> Results = Zk.multi(ops)
> This causes an exception to be thrown on the first path that doesn't
> exist. It doesn't return back a list with one OpResult flagged with an
> error. I was under the impression I'd get back a bunch of OpResult objects
> with flags of error, or otherwise, and then I could build another list of
> operations to create what's needed (which, even if it did work, the
> CheckResult object doesn't include the path, so I'm just hoping the
> results are in the same order as the operations were listed in, as I have
> to infer the path I'll need to build from the position of the OpResult in
> the list).
> On 3/1/12 3:05 PM, "Ted Dunning" <ted.dunning@gmail.com> wrote:
>> No. I meant one call full of checks and a second call with any necessary
>> creates. 
>> Sent from my iPhone
>> On Mar 1, 2012, at 11:17 AM, "Shelley, Ryan" <Ryan.Shelley@disney.com>
>> wrote:
>>> Ok, I tried this with the Op.create and found that it will throw a
>>> KeeperException on the first path that doesn't exist. It doesn't return
>>> back an OpResult with an "error" type. I can still use this, and just
>>> catch the exception and create the node in the exception, but I was
>>> under
>>> the impression that I could do this in two trips. One trip to get back a
>>> list of OpResults from the check that would inform me if the path
>>> existed
>>> or not, and a second trip to create all the paths that don't exist (and
>>> as
>>> a note, the CheckResult object doesn't include the path, so I have to
>>> infer it from the order of my original list of paths used to create the
>>> multi-check).
>>> -Ryan
>>> On 2/29/12 7:16 PM, "Ted Dunning" <ted.dunning@gmail.com> wrote:
>>>> On Wed, Feb 29, 2012 at 7:04 PM, Marshall McMullen <
>>>> marshall.mcmullen@gmail.com> wrote:
>>>>> Yes, Ted's right. The multi has to fail as that's part of the contract
>>>>> it
>>>>> guarantees.
>>>>> The only thing you could do, which will significantly narrow the race
>>>>> condition, is as you're *building *the multi, check if the path
>>>>> already
>>>>> exists. If so, then don't add the create op for that path into the
>>>>> multi.
>>>>> Of course this may not work in every situation, but we use that
>>>>> approach in
>>>>> many code paths and it works well.
>>>> Another approach is to compose one multi with Op.exists() for each
>>>> level
>>>> so
>>>> that you find everything you need, then create another with the correct
>>>> Op.create() operations.  That gets the problem down to two server
>>>> round-trips but still has the race condition.

View raw message