From: Ted D. <tdu...@ve...> - 2008-04-25 16:41:24
|
Another viable approach is to use a BlockingQueue where elements are added in the watcher. The producer: for (int i = 0; i < 10; i++) { client.create(katta + "/" + i); } client.create(katta + "/DONE") The consumer: Queue q = new BlockingQueue; void consumer() { int count = 0; watcher.process(null) Object item = q.take(); while (!(item instanceOf EndMarker)) { counter++ item = q.take() } The watcher: int lastZxid = 0 void process(WatcherEvent event) { Stat s List<String> items = client.getChildren(katta, true) int max = lastZxid for (String x : items) { s = client.exists(x, false) if (s.getMzxid() > lastZxid) { q.put(x) max = s.getMzxid() } } lastZxid = max if (client.exists(katta + "/DONE") { q.put(new EndMarker()) } } I find this idiom more natural. In many cases, there is no need for an end marker since there is no conceptual limit to the items that need to be processed. (note that this was code written off the cuff and not debugged ... I signal this by omitting lots of real syntax) synchronized (listener._mutex) { listener._mutex.wait(); } } assertEquals(10, listener._counter); ... in the Watcher... public void process(WatcherEvent event) { _counter++; synchronized (_mutex) { _mutex.notify(); } } On 4/25/08 12:04 AM, "Stefan Groschupf" <sg...@10...> wrote: > Hi Ben, > thanks a lot for the clarification. That helped a lot. > Sorry for the traffic but working with zookeeper is super productive, > and things moving very fast. :) >> A change happened (/c got created) when you didn't have a watch set. >> > > > Just for the mail archive.. > My mistake basically was to just synchronize against the same mutex in > process and create. > Though the right way is to wait until the notification is triggered > before a new create is called. > > in the test: > ... > for (int i = 0; i < 10; i++) { > client.create(katta + "/" + i); > synchronized (listener._mutex) { > listener._mutex.wait(); > } > } > assertEquals(10, listener._counter); > ... > in the Watcher... > public void process(WatcherEvent event) { > _counter++; > synchronized (_mutex) { > _mutex.notify(); > } > > } > >> ----- Original Message ---- >> From: Stefan Groschupf <sg...@10...> >> To: zoo...@li... >> Sent: Thursday, April 24, 2008 10:19:16 PM >> Subject: [Zookeeper-user] [Bug?] Notification not guaranteed >> >> Hi there, >> as far I understand notification is guaranteed for e.g. child >> creation. >> However I have a test that shows that randomly I do not get all >> notification I do expect. >> I basically create 10 child in /folder but only get 8 or 9 >> notifications back. >> However in case I add a Thread.sleep(50); between my child znode >> creation I always get 10 notifications. >> >> Is that a bug or an optimization, e.g. getting one notification for >> two new sub znode creations? >> Thanks for any hints. >> Stefan >> >> My code looks like this: >> >> TestMethod: >> >> public void testNotifications() throws Exception { >> KattaConfiguration conf = new KattaConfiguration(); >> Server server = new Server(conf); >> ZKClient client = new ZKClient(conf); >> MyListener listener = new MyListener(); >> String katta = "/katta"; >> if (client.exists(katta)) { >> client.deleteRecursiv(katta); >> } >> client.create(katta); >> client.subscribeChildChanges(katta, listener); >> for (int i = 0; i < 10; i++) { >> client.create(katta + "/" + i); >> // Thread.sleep(50); >> } >> Thread.sleep(1000); >> assertEquals(10, listener._counter); >> server.shutdown(); >> } >> >> Watcher process Method: >> >> public void process(WatcherEvent event) { >> synchronized (_mutex) { >> String path = event.getPath(); >> if (event.getType() == >> Watcher.Event.EventNodeChildrenChanged) { >> HashSet<IZKEventListener> listeners = >> _childListener.get(path); >> if (listeners != null) { >> for (IZKEventListener listener : listeners) { >> listener.process(event); >> } >> // re subscribe to event. >> try { >> _zk.getChildren(event.getPath(), true); >> } catch (Exception e) { >> for (IZKEventListener listener : listeners) { >> removeListener(path, listener); >> } >> Logger.warn("unable to re subscribe to child >> change notification", e); >> } >> } >> } >> } >> } >> >> >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 101tec Inc. >> Menlo Park, California, USA >> http://www.101tec.com >> >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >> Don't miss this year's exciting event. There's still time to save >> $100. >> Use priority code J8TL2D2. >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaon>> e >> _______________________________________________ >> Zookeeper-user mailing list >> Zoo...@li... >> https://lists.sourceforge.net/lists/listinfo/zookeeper-user >> >> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 101tec Inc. > Menlo Park, California, USA > http://www.101tec.com > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Zookeeper-user mailing list > Zoo...@li... > https://lists.sourceforge.net/lists/listinfo/zookeeper-user |