hadoop-zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Reed <br...@yahoo-inc.com>
Subject RE: Sending data during NodeDataChanged or NodeCreated
Date Thu, 08 Jan 2009 19:06:32 GMT
I think you are looking at the race condition backwards. (and this btw is where the users had
many of their bugs.) remember watches are one time triggers. so if you get a watch event it
means a change has happened, so if /a is changed to 1 and then changed to 2. the data that
will come back in the watch event will be 1, but the latest data will be 2.

if the application uses 1 from the watch event and runs with that, it will not be using the
latest value. it will not even know that it isn't using the latest value since it will never
get another watch event when /a is set to 2.

generally, applications use watches to monitor a value. in that case you never would want
to use the value you get from the watch. instead, you use the value you get from the read
that reregisters the watch.

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
invalid it was very hard to diagnose.

we don't want to make zookeeper harder to use by introducing mechanisms that only work with
subtle assumptions.

ben

-----Original Message-----
From: burtonator@gmail.com [mailto:burtonator@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 NodeDataChanged or NodeCreated

On Wed, Jan 7, 2009 at 9:25 AM, Benjamin Reed <breed@yahoo-inc.com> 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 results in death, you should stop handing it out.
>

I think this is excessive rope...

Most people want to read the data and having a race here is just asking for
trouble.

I'm not sure it is as much about excessive rope is it is about making it
easy for users to stumble on the correct use case and reduce bugs.

Ignorance is a wonderful gift you can give to your users :)



>
> In your example, if the ACL changed and then the data changed, we would
> have a security hole if we sent the data with the watch.
>

I thought you might mention that. :) Technically there wouldn't be a
security hole if the operation was this:
- set foo to 'asdf'
- set ACL to foo blocking everyone reading it...

If you needed to prevent a read of 'asdf' you need to do this:

- set ACL to foo blocking everyone reading it...
- set foo to 'asdf'

When they are 1ms apart it's hard to understand but imagine if they were 10
hours apart.

Technically, there would be a 1ms window where clients could do a getData()
on the file and read the value.

Kevin

-- 
Founder/CEO Spinn3r.com
Location: San Francisco, CA
AIM/YIM: sfburtonator
Skype: burtonator
Work: http://spinn3r.com

Mime
View raw message