Hi, Flavio: HBASE-8365 is one such case. Let me search around for other related discussion.
On Fri, Jan 17, 2014 at 11:17 AM, Flavio Junqueira <[email protected]>wrote: > Hi Ted, > > Can you provide more detail on how the precise deltas could make it more > robust? > > -Flavio > > -----Original Message----- > From: "Ted Yu" <[email protected]> > Sent: 17/01/2014 17:25 > To: "[email protected]" <[email protected]> > Subject: Re: Where are we in ZOOKEEPER-1416 > > Having the ability to know exact deltas would help make HBase region > assignment more robust. > > Cheers > > > On Fri, Jan 17, 2014 at 9:13 AM, kishore g <[email protected]> wrote: > > > I agree with you, I like the side effect and in fact I would prefer to > have > > one notification for all changes under a parent node. > > > > However, Hao is probably asking for ability to know exact deltas. > > > > > > On Fri, Jan 17, 2014 at 8:15 AM, FPJ <[email protected]> wrote: > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > >
