Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB