Thanks Travis, I've slated this for 3.4.0, I think it would be useful to
add more examples so feel free to add more if you have any ideas for
useful ones.
For future reference, we ask that contributions come in the form of a patch:
http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute
It's fine this time around, but in future it would be helpful.
(also click on "submit patch" link when you are ready for review - that
pushes it through the process, incl automated testing/verification,
that's why we ask for a patch off the root btw)
Thanks!
Patrick
On 05/04/2010 04:00 PM, Travis Crawford wrote:
On Tue, May 4, 2010 at 3:45 PM, Ted Dunning<ted.dunn...@gmail.com> wrote:
Travis,
Attachments are stripped from this mailing list. Can you file a JIRA and
put your attachment on that instead?
Here is a link to get you started:
https://issues.apache.org/jira/browse/ZOOKEEPER
Whoops. Filed:
https://issues.apache.org/jira/browse/ZOOKEEPER-765
--travis
On Tue, May 4, 2010 at 3:43 PM, Travis Crawford<traviscrawf...@gmail.com>wrote:
Attached is a skeleton application I extracted from a script I use --
perhaps we could add this as a recipe? If there are issues I'm more
than happy to fix them, or add more comments, whatever. It took a
while to figure this out and I'd love to save others that time in the
future.
--travis
On Tue, May 4, 2010 at 3:16 PM, Mahadev Konar<maha...@yahoo-inc.com>
wrote:
Hi Adam,
I don't think zk is very very hard to get right. There are exmaples in
src/recipes which implements locks/queues/others. There is ZOOKEEPER-22
to
make it even more easier for application to use.
Regarding re registration of watches, you can deifnitely write code and
submit is as a part of well documented contrib module which lays out the
assumptions/design of it. It could very well be useful for others. Its
just
that folks havent had much time to focus on these areas as yet.
Thanks
mahadev
On 5/4/10 2:58 PM, "Adam Rosien"<a...@rosien.net> wrote:
I use zkclient in my work at kaChing and I have mixed feelings about
it. On one hand it makes "easy things easy" which is great, but on the
other hand I very few ideas what assumptions it makes "under the
hood". I also dislike some of the design choices such as unchecked
exceptions, but that's neither here nor there. It would take some
extensive documentation work by the authors to really enumerate the
model and assumptions, but the project doesn't seem to be active
(either from it being adequate for its current users or just
inactive). I'm not sure I could derive the assumptions myself.
I'm a bit frustrated that zk is "very, very hard to really get right".
At a project level, can't we create structures to avoid most of these
errors? Can there be a "standard model" with detailed assumptions and
implementations of all the recipes? How can we start this? Is there
something that makes this too hard?
I feel like a recipe page is a big fail; wouldn't an example app that
uses locks and barriers be that much more compelling?
For the common FAQ items like "you need to re-register the watch",
can't we just create code that implements this pattern? My goal is to
live up to the motto: a good API is impossible to use incorrectly.
.. Adam
On Tue, May 4, 2010 at 2:21 PM, Ted Dunning<ted.dunn...@gmail.com>
wrote:
In general, writing this sort of layer on top of ZK is very, very hard
to
get really right for general use. In a simple use-case, you can
probably
nail it but distributed systems are a Zoo, to coin a phrase. The
problem is
that you are fundamentally changing the metaphors in use so assumptions
can
come unglued or be introduced pretty easily.
One example of this is the fact that ZK watches *don't* fire for every
change but when you write listener oriented code, you kind of expect
that
they will. That makes it really, really easy to introduce that
assumption
in the heads of the programmer using the event listener library on top
of
ZK. Another example is how the atomic get content/set watch call works
in
ZK is easy to violate in an event driven architecture because the
thread
that watches ZK probably resets the watch. If you assume that the
listener
will read the data, then you have introduced a timing mismatch between
the
read of the data and the resetting of the watch. That might be OK or
it
might not be. The point is that these changes are subtle and tricky to
get
exactly right.
On Tue, May 4, 2010 at 1:48 PM, Jonathan Holloway<
jonathan.hollo...@gmail.com> wrote:
Is there any reason why this isn't part of the Zookeeper trunk
already?
