Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Zookeeper >> mail # user >> Create nested paths


+
Shelley, Ryan 2012-03-01, 00:08
+
Ted Dunning 2012-03-01, 00:23
+
Shelley, Ryan 2012-03-01, 00:26
+
Ted Dunning 2012-03-01, 00:46
+
Shelley, Ryan 2012-03-01, 00:52
+
Ted Dunning 2012-03-01, 02:59
+
Marshall McMullen 2012-03-01, 03:04
+
Ted Dunning 2012-03-01, 03:16
+
Shelley, Ryan 2012-03-01, 19:17
+
Ted Dunning 2012-03-01, 23:05
+
Shelley, Ryan 2012-03-01, 23:14
+
Marshall McMullen 2012-03-01, 23:27
+
Shelley, Ryan 2012-03-01, 23:30
Copy link to this message
-
Re: Create nested paths
Harrumph.

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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
>> 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" <[EMAIL PROTECTED]> wrote:
>>>
>>>> On Wed, Feb 29, 2012 at 7:04 PM, Marshall McMullen <
>>>> [EMAIL PROTECTED]> 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.
>>>
>
+
Marshall McMullen 2012-03-01, 23:28
+
Shelley, Ryan 2012-03-01, 18:13
+
Ted Dunning 2012-03-01, 23:02
+
Marshall McMullen 2012-03-01, 18:15
+
Shelley, Ryan 2012-03-01, 18:46
+
Shelley, Ryan 2012-03-01, 05:29