zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: thread pool executor for event dispatch
Date Mon, 15 Aug 2011 22:41:52 GMT
And to add to this, the ordering guarantees that ZK provides are perhaps the
most important of all.  They are what allows proper reasoning.

The application can always push work into an execution pool from the actual
watcher if threaded response makes sense.  That avoids blocking the
notification thread and allows whatever level of concurrency is appropriate.

On Mon, Aug 15, 2011 at 3:38 PM, Mahadev Konar <mahadev@hortonworks.com>wrote:

> Martin,
>  The problem with using a thread pool is that it becomes difficult to make
> sense about order of events that occur in the system.
> Here is the snippet from ZK wiki on client guarantees:
> What ZooKeeper Guarantees about Watches
> With regard to watches, ZooKeeper maintains these guarantees:
>        • Watches are ordered with respect to other events, other watches,
> and asynchronous replies. The ZooKeeper client libraries ensures that
> everything is dispatched in order.
>        • A client will see a watch event for a znode it is watching before
> seeing the new data that corresponds to that znode.
>        • The order of watch events from ZooKeeper corresponds to the order
> of the updates as seen by the ZooKeeper service.
> hope that helps
> mahadev
> On Aug 15, 2011, at 2:15 PM, Martin Serrano wrote:
> > Hi,
> >
> > Has the zookeeper community considered adding an option to use a thread
> pool executor for event dispatch?  One pattern we have developed for our
> library is to trigger event listeners in a separate thread to guard against
> blocking operations in listeners.  A blocking watcher will prevent new
> events/watchers from being triggered.  By adding the ability to configure
> which Executor was used by a zookeeper client for event delivery library
> writers could make the choice that is best for them.  Being able to do this
> at the client level (rather than for each individual watcher class I
> implement) is a cleaner approach IMO.
> >
> > Thoughts?
> >
> > -Martin

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message