We don't need to have a mapping between every change and a notification. If there are 2+ changes between notifications, you'll be able to observe it by reading the ZK state. In fact, one nice side-effect is that we reduce the number of notifications when there are many concurrent changes.
The only situation I can see it being necessary is the one in which we need to know precisely the changes and we haven't cached a previous version of the state. -Flavio > -----Original Message----- > From: kishore g [mailto:[email protected]] > Sent: 17 January 2014 16:06 > To: [email protected] > Subject: Re: Where are we in ZOOKEEPER-1416 > > I think Hao is pointing out that there is no way to see every change > (delta) that happened to a znode. Consider 2 changes A,B in quick > succession. When client gets notified of A and before setting the watch the > change B has occurred on the server side. This means the client cannot know > the delta A. Client can only read the state after change B is applied. > > Implementing the concept of Persistent watcher guarantees that client if > notified after every change. > > This is a nice to have feature but I dont understand the requirement in Hbase > where this is needed. Hao, can you shed more light on how this would be > useful for HBase (to act like state machine) > > thanks, > Kishore G > > > > > > > > > On Fri, Jan 17, 2014 at 5:18 AM, FPJ <[email protected]> wrote: > > > But you don't really miss events, you'll see them when you read the ZK > > state. If you follow the pattern I described, you're supposed to > > observe all changes. Perhaps I'm missing some concrete use case you > > have mind. > > > > -Flavio > > > > > -----Original Message----- > > > From: 陈迪豪 [mailto:[email protected]] > > > Sent: 17 January 2014 13:03 > > > To: [email protected] > > > Subject: RE: Where are we in ZOOKEEPER-1416 > > > > > > No, it's not complicated. But for the people who don't understand zk > > deeply, > > > they would easily ignore the fact that they would miss events in > > > some > > way. > > > Moreover, I think providing persistent watch is good for developers > > > to > > build > > > the "state-machine" application. Actually, HBase suffer from missing > > > the intermediate state when use zk to store the data. > > > > > > If the feature is implemented, I would like to see the patch and > > > consider > > if it > > > can be used for us. > > > > > > ________________________________________ > > > From: Flavio Junqueira [[email protected]] > > > Sent: Friday, January 17, 2014 8:12 PM > > > To: [email protected] > > > Subject: RE: Where are we in ZOOKEEPER-1416 > > > > > > My take is that persistent subscriptions add complexity and are not > > strictly > > > necessary. You can follow this pattern of setting a watch, reading > > > the > > state > > > upon a notification and setting a new watch. Why do you feel that's > > > complicated? > > > > > > -Flavio > > > > > > -----Original Message----- > > > From: 陈迪豪 [mailto:[email protected]] > > > Sent: Friday, January 17, 2014 3:13 AM > > > To: [email protected] > > > Subject: Where are we in ZOOKEEPER-1416 > > > > > > > > > > > > Persistent watch and implementing the feature to act like "state > machine" > > > which is mentioned in > > > ZOOKEEPER-153<https://issues.apache.org/jira/browse/ZOOKEEPER- > 153>, > > > would be great for ZooKeeper user. I think HBase would like to know > > > all > > the > > > change in zk rather than missing kind of events. > > > > > > So, would we continue developing these features? It's also a little > > > complicated to develop with zk and I think there're lots of things > > > to > > improve. > > > > > >
