zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mahadev Konar <maha...@hortonworks.com>
Subject Re: thread pool executor for event dispatch
Date Mon, 15 Aug 2011 22:38:24 GMT
 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

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

View raw message