RE: Sending data during NodeDataChanged or NodeCreated
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 the watch and get the new value. (re-registering watches on reconnect is a different issue. there are no disconnects in this example.) you are correct that zookeeper has some subtle things to watch out for. that is why we do not want to add more. ben -Original Message- From: burtona...@gmail.com [mailto: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 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. I don't quite follow. In this scenario you would be sent two events, with two pieces of data. If ZK re-registers watches on reconnect, I don't see how it could be easier than this. we don't want to make zookeeper harder to use by introducing mechanisms that only work with subtle assumptions. I definitely think ZK has too much rope right now. It's far too easy to make mistakes and there are lots of subtle undocumented behaviors. Kevin -- Founder/CEO Spinn3r.com Location: San Francisco, CA AIM/YIM: sfburtonator Skype: burtonator Work: http://spinn3r.com
Re: Sending data during NodeDataChanged or NodeCreated
On Wed, Jan 7, 2009 at 9:25 AM, Benjamin Reed br...@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
Re: Sending data during NodeDataChanged or NodeCreated
On Wed, Jan 7, 2009 at 12:46 PM, Kevin Burton bur...@spinn3r.com wrote: On Wed, Jan 7, 2009 at 9:25 AM, Benjamin Reed br...@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 :) Perhaps a compromise would be augment the API, or your wrapper, such that it provides a Futurebyte[] which has more well-known semantics to clients. .. Adam
