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
