Thank you, Ted. As far as getChildren goes, you are right. Since you will get the latest children change and at the same time set a watch, you will definitely not lose any children node change.
Thank you. Chang Nov 13, 2010, 12:51 PM, Ted Dunning 작성: > Persistent watches were omitted from ZK on purpose because of the perceived > danger of not have a load shedding mechanism. > > Note that when you get a notification, the query you do to get the next > state typically sets the next watch. This guarantees that you don't lose > anything, but it may mean that you effectively get notified of multiple > changes in one notification. > > If you really, really want all notifications in order, then what you are > really looking for is a kind of a distributed transaction log. For small > applications, you can implement this by writing logs into ZK znodes. Your > client should remember where they were and as they are notified, they read > the current file to catch up. This has the downside that to update a file > you have to completely rewrite it which makes it inconvenient to put a bunch > of stuff into a single chunk of the log. You would also need a watcher on > the directory to notify you when new log files are created. Aside from the > slightly quadratic update problem, this does what you need. > > You can also check out Bookkeeper which is a more scalable distributed > transaction logging system. It addresses the complications of (mis) using > ZK as a log system and attempts to give you a reliable and robust > transaction log. > > On Fri, Nov 12, 2010 at 7:16 PM, Chang Song <tru64...@me.com> wrote: > >> >> Hi. >> >> It's been a couple of weeks since we started integrating zookeeper into our >> app. >> Great piece of software. Cut down LOC by more than half. >> Thank you for open sourcing Zookeeper. >> >> I have a couple of questions, though. >> I was wondering you have any plan to support persistent watch stream >> feature? >> >> One-time watch is very inconvenient for us. >> We need to get a stream of notifications in order. We are talking thousands >> of clients. >> Since notification can happen in bulk, we need to set a watch first, and >> once we get a callback, >> we need to check periodically what happens to the children of the watch >> nodes. >> >> You can consider this as a automatic server-side watch registration >> feature: I'd call this sticky watch. >> I think it is easier to implement this as a sticky watch. >> >> Another question is if it is possible to coalesce predefined number of >> changes for watch callbacks. >> We have observed that if there are many changes in children node, clients >> gets different number of >> messages in bulks. This makes the architecture of our application from >> event-driven to polling for a while. >> Thus pretty much the same reasoning behind the first question. >> >> Any comments welcome. >> >> Thank you. >> >> Chang >> >> >> >>
