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
+
Ted Dunning 2012-03-01, 23:25
Copy link to this message
-
Re: Create nested paths
Marshall McMullen 2012-03-01, 23:28
Check is just handled the same as the other ops. In the
PrepRequestProcessor stage if the requested path doesn't exist, then it
aborts the multi with an error.

On Thu, Mar 1, 2012 at 11:25 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:

> 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.
> >>>
> >
>
+
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