Hey guys. I think I'm finally in the position to push ZK into production for a while to test it out.
My biggest feedback (other than the small bugs I found) was that the API could be a bit simpler. I codified my thoughts here: http://pastebin.com/f2ecea8c7 http://pastebin.com/f62a01e9 Basically, I was thinking that one could receive an onData event to receive the initial value. Then all future events would call onData..... I was thinking that an onExists() method might also be nice. The current API could be made cleaner with: - one or two standalone Listener interfaces with onFoo methods for each event type. - the processResults() method is the same for each interface right now which is somewhat confusing. Using onFoo is more self documenting. - using the main thread by using poll() to wait for events from ZooKeeper. I use a ConcurrentLinkedQueue in my implementation. Also, is there a race condition between when the client receives an event for an update and before it can request a new one? I was thinking session local based events would solve this problem (you register your watch once per session and then get all events until it is unregistered). I think this can be solved in my code by reading the current version of the value from the getData() method I call when I register the new watch and comparing it to the last version I saw. If it was incremented then I would call onData again. The problem here is that I might miss two updates (but at least I would receive the last stable value). Kevin -- Founder/CEO Spinn3r.com Location: San Francisco, CA AIM/YIM: sfburtonator Skype: burtonator Work: http://spinn3r.com
