Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # dev >> Where are we in ZOOKEEPER-1416


Copy link to this message
-
RE: Where are we in ZOOKEEPER-1416
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.
> >
> >
> >