zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Extracting Zab from Zookeeper
Date Mon, 31 Jan 2011 00:56:05 GMT
FWIW, we have this crazy idea of using something like an extracted ZAB for maintaining quorum-cliques
in a modified HBase cluster: https://issues.apache.org/jira/browse/HBASE-2357

   - Andy

> From: Benjamin Reed <breed@yahoo-inc.com>
> Subject: Re: Extracting Zab from Zookeeper
> To: "dev@zookeeper.apache.org" <dev@zookeeper.apache.org>
> Cc: "Ted Dunning" <ted.dunning@gmail.com>, "user@zookeeper.apache.org" <user@zookeeper.apache.org>
> Date: Friday, January 28, 2011, 10:27 AM
> flavio and ted are correct. zab and
> zookeeper are tightly coupled, and 
> as flavio points out, zab provides a bit more than just
> atomic broadcast.
> 
> i think it would be a good thing to do for three reasons:
> 
> 1) it would make testing, benchmarking, and fixing that layer 
> (especially for ZOOKEEPER-22) much easier.
> 2) we could try different backends easier. (i'd love to try
> using bookkeeper for example.)
> 3) although the zab interface must be richer than normal
> atomic broadcast (access to past transactions, for example), i
> think in practice applications that do primary/backup can benefit
> from this richer interface.
> 
> ben
> 
> On 01/28/2011 07:03 AM, Ted Dunning wrote:
> > I think that what Flavio was saying is that it is like
> > pulling a string on a sweater.  Almost any application that
> > wants ZAB is probably going to need the broadcast and they the
> > broadcast, they will want to have logging.  And transactions.
> >  And so on.
> >
> > Moreover, some of these features are not necessarily
> > encoded in ZK in a way that you can point to.  Instead they are
> > enabled by the way that several functional units are glued
> > together.



      

Mime
View raw message