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 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? > >>>> > >>> > > > > >
