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