Re: [Bigdata-developers] Why zookeeper?

[Fred O. <fko...@gm...>]

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