Hi,
Im going to be using Zookeeper quite extensively for a project in a
few weeks, but development hasn't kicked off yet. This means I have
some time on my hands and I'd like to get familiar with zookeeper
beforehand by perhaps writing some tools to make debugging problems
with it easier
awesome! that would be great ivan. i'm sure pat has some more concrete
suggestions, but one simple thing to do is to run the unit tests and
look at the log messages that get output. there are a couple of
categories of things that need to be fixed (this is in no way exhaustive):
1) messages
Take a look at the logging page in the docs:
http://hadoop.apache.org/zookeeper/docs/current/zookeeperInternals.html#sc_logging
Some good guidelines in there. Basically we log things at info level
that are interesting/informational but not logged so frequently that
they fill the log. WARN is
hiļ¼all
we'd like to store some metadata in zookeeper in our upcoming project, here
is a special but common case: we need to create a new znode, in the mean while,
update another znode data. These manipulation(a create and a update) need to be
done as atom. We don't want to see a successful
This is not a good thing. ZK gains lots of its power and reliability by not
trying to do atomic updates to multiple znodes at once.
Can you say more about the update that you want to do? It is common for
updates like to be such that you can order the updates and do without a
truly atomic
Thanks for your quick reply, Ted.
we are implementing a distributed system, using zookeeper for master metedata
persistence. There's DISK object and DISK-PAIR object. when creating a
DISK-PAIR, we need to first create a znode indicating DISK-PAIR object and
updating the corresponding two
On 29 March 2010 19:10, Ted Dunning ted.dunn...@gmail.com wrote:
This is not a good thing. ZK gains lots of its power and reliability by
not
trying to do atomic updates to multiple znodes at once.
Ted -
Could you say a bit about how you feel ZK would sacrifice power and
reliability through
I perhaps should not have said power, except insofar as ZK's strengths are
in reliability which derives from simplicity.
There are essentially two common ways to implement multi-node update. The
first is the tradtional db style with begin-transaction paired with either a
commit or a rollback
Do the DISK objects contain a reference to a DISK-PAIR? What about the
reverse?
Can DISK's be in more than one DISK-PAIR?
I will assume some answers to these so I can give a design.
Suppose that DISK's just contain other information, but do not refer to
DISK-PAIR's and and can only exist in a
