Re: [Bigdata-developers] Why zookeeper?

[Bryan T. <br...@sy...>]

Fred,

I really do not want to get into the Jini/Zookeeper thing.  Both are great frameworks.  They do overlap a bit, but they are being used in ways which emphasize their respective strengths.

I think that the runtime binding approach you are outlining may cause problems with the quorum semantics and definitely will cause problems with encapsulating instance based versus rules based functionality within the architecture.  However, static binding will reduce risk above the basic instance based configuration you have advocated and reflects a separation of concerns between static instance configuration (or dynamic rules based configuration) on the one hand and quorum dynamics on the other hand.  I am not willing to go the additional step to dynamic binding since believe that it could undermine the quorum dynamics and it will make it difficult to encapsulate the rules based versus instance based mechanisms.

I think that this separation of concerns is a reasonable compromise in the architecture and I think that it gives you the freedom you are asking for from the "complexity" of the rules based configuration mechanisms.  At this point, I would like to get beyond this discussion and focus on completing the HA milestone.

Thanks,
Bryan

> -----Original Message-----
> From: Fred Oliver [mailto:fko...@gm...] 
> Sent: Tuesday, August 03, 2010 2:11 PM
> To: Bryan Thompson
> Cc: Bigdata Developers
> Subject: Re: [Bigdata-developers] Why zookeeper?
> 
> Bryan,
> 
> > No, it is not the same cost. Zookeeper is a trigger based 
> mechanism. Clients register a watch (aka trigger) and are 
> notified if the watched condition is satisified.  It depends 
> on how you set things up of course, but polling a service to 
> discover whether it is the leader can incur more cost and can 
> be broken because Jini/River is not providing atomic decision 
> making about leader elections.
> 
> I don't see the difference. The River lookup service has a 
> better event system, and its clients will receive 
> notification of changes of service entries (including 
> leadership changes if services place that information there). 
> I agree that polling is not reasonable. The election of a 
> leader may be (mostly) atomic, but the distribution of the 
> result of the election is asynchronous in either case.
> 
> > Concerning a stateless service to handle binding, I would 
> question whether it could make the binding decisions 
> correctly in the case of a network partition.  You might wind 
> up with two such instances making their decisions 
> independently, at which point all bets are off.
> 
> I expect that only one such service instance need exist in 
> the cluster and only for a short time (until physical 
> services are bound to logical services). It is probably 
> desirable to wait for the partition to be healed in order to 
> bind physical services on opposite sides of the fault which 
> caused the partition. The delay in bringing a new logical 
> service into an existing cluster will not interfere with the 
> operation of the cluster in the short term.
> 
> > I think that my suggestion of generating and deploying the 
> configuration files automatically removes everything 
> associated with rules based configuration versus instance 
> based configuration.  You can not safely step beyond that 
> point and erode the core functionality of zookeeper for 
> distributed synchronous decision making dynamics without 
> proposing a suitable replacement.  Jini/River does not handle 
> this, which is why Zookeeper is part of the services architecture.
> 
> I don't propose replacing zookeeper for making the group 
> leadership decisions. Otherwise, removing the "distributed 
> synchronous decision making dynamics" where it is not 
> absolutely needed is the significant simplification I 
> propose. Removing synchronous behavior from asynchronous 
> processes makes the code easier to understand, reason about 
> correctness, write, test and maintain.
> 
> Generating and deploying individual configuration files is a 
> plan, but that does not disconnect JiniFederation (which is 
> still needed) from its use of zookeeper (which is not needed 
> in the instance-based configuration).
> 
> Other than the leadership election mechanism (which can be 
> limited to the group from whom the leader is elected) and the 
> rules-based startup mechanism, what is it that River does not handle?
> 
> Fred
>