On Thu, Jan 8, 2009 at 2:07 PM, Benjamin Reed wrote:
> if you do a getData("/a", true) and then "/a" changes, you will get a watch
> event. if "/a" changes again, you will not get an event. so, if you want to
> monitor "/a", you need to do a new getData() after each watch event to
> reregister th
burtona...@gmail.com] On Behalf Of Kevin
Burton
Sent: Thursday, January 08, 2009 11:58 AM
To: zookeeper-user@hadoop.apache.org
Subject: Re: Sending data during NodeDataChanged or NodeCreated
>
>
> while the case in which a value only changes once, can be made slightly
> more optimal by p
>
>
> while the case in which a value only changes once, can be made slightly
> more optimal by passing the value in the watch event. it is not worth the
> risk. in our experience we had a application that was able to make that
> assumption initially and then later when the assumption became invali
mechanisms that
only work with subtle assumptions.
ben
-Original Message-
From: burtona...@gmail.com [mailto:burtona...@gmail.com] On Behalf Of Kevin
Burton
Sent: Wednesday, January 07, 2009 12:46 PM
To: zookeeper-user@hadoop.apache.org
Subject: Re: Sending data during NodeData
> Perhaps a compromise would be augment the API, or your wrapper, such
> that it provides a Future which has more well-known semantics
> to clients.
>
Already there :)
I'll publish the source once my second pass is done and I believe I've
removed all the rope.
Kevin
--
Founder/CEO Spinn3r.com
L
On Wed, Jan 7, 2009 at 12:46 PM, Kevin Burton wrote:
> On Wed, Jan 7, 2009 at 9:25 AM, Benjamin Reed wrote:
>
>> This is the behavior we had when we first implemented the API, and in every
>> case where people used the information there was a bug. it is virtually
>> impossible to use correctly. I
On Wed, Jan 7, 2009 at 9:25 AM, Benjamin Reed wrote:
> This is the behavior we had when we first implemented the API, and in every
> case where people used the information there was a bug. it is virtually
> impossible to use correctly. In general I'm all for giving people rope, but
> if it always
This is the behavior we had when we first implemented the API, and in every
case where people used the information there was a bug. it is virtually
impossible to use correctly. In general I'm all for giving people rope, but if
it always results in death, you should stop handing it out.
In your
>
> > It's almost certainly what the user wants anyway.
> Its just that the watches are pretty lightweight and sending bytes around
> is
> just more work to do at the server. Though we should experiment with how
> much more load it generates and how useful would it be to send out the
> bytes
> with
> So if I understand this correctly, if I receive a NodeDataChanged event, and
> then attempt do do a read of that node, there's a race condition where the
> server could crash and I would be disconnected and my read would hit an
> Exception
> Or, the ACL could change and I no longer have permiss
10 matches
Mail list logo
