zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or exclusive Write Lock protocol/policy
Date Fri, 18 Jul 2008 12:30:07 GMT
As a newbie around hadoop/zookeeper (but long time apache hacker on
various things), I think the high level protocol/recipe stuff should
definitely be a separate, released module; so folks who wanna use it
can share a versioned binary and so forth. It would be awesome to have
a few good protocols/recipes for things like leader election, write
locks, read/write locks - maybe load balancing (e.g. sparse hash maps
and whatnot) - plus maybe more distributed java-util-concurrent stuff
like barriers etc. Even if folks don't reuse the recipes at least they
can act as good educational material for using the core ZK client API
etc.

I don't see a huge need yet to split these Java recipe's into multiple
individual releases/jars yet - as we're talking a pretty small
codebase, so a single zookeeper-recipe.jar would suffice for now. e.g.
for leader election & exclusive write locks we're talking two classes
probably; maybe with a few interface hooks or something. I'd be
tempted to stick with all the recipe's in a single jar for now - then
if we find some complex recipe's coming along that are more
specialised and require loads of code, we could spin those out later
but many of the core recipe's are gonna be pretty small in terms of
code and I can also see a small chunk of code being reusable in a few
recipe's etc. (e.g. exclusive write locks are kinda the same thing as
leader election).

The bigger decision is more do we release the core Java API/impl to ZK
with the recipe's or as a separate release process. Certainly the core
of ZK is pretty stable; the recipe's are gonna be in a state of flux &
rapid development (hopefully!:) for a while. Its gonna be a while
before all the recipes are totally finished & hardened; but I don't
see why they can't be released in a kinda work-in-progress state. e.g.
so long as we document that the recipe code may change in the future,
I don't see any issue including the recipe code along with the ZK
client and server in a single release. But down the line we could
always split it up if we need to.

I tend to prefer deferring decisions until we really need to and
saving work where possible (particularly when it comes to things like
doing releases); so for now I'd prefer to release the recipe's in the
Java ZK client/server release distro as a separate optional jar (along
with some warnings the recipe's are work in progress and might change
a little over the next few months as we figure out the neatest way to
implement the higher level protocols etc) plus separate documentation
stuff.

-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com

Mime
View raw message