Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (athena.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.216.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <FC689640-C099-48EB-93EE-C038AF63B6CE@hortonworks.com>
References: 
 <9694A6C3D68A4249BD9E1A875B6BA81E0349CF518F@bos0ex01.corp.attivio.com>
 <FC689640-C099-48EB-93EE-C038AF63B6CE@hortonworks.com>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Mon, 15 Aug 2011 15:41:52 -0700
Message-ID: 
 <CAJwFCa1fAy+9fN2ob1A7KQ2t4XhLSOjq0VULNNxMyk60_SM4mA@mail.gmail.com>
Subject: Re: thread pool executor for event dispatch
To: user@zookeeper.apache.org
Content-Type: multipart/alternative; boundary=485b397dcd9957d95b04aa92f9ce

--485b397dcd9957d95b04aa92f9ce
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

And to add to this, the ordering guarantees that ZK provides are perhaps th=
e
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>wro=
te:

> Martin,
>  The problem with using a thread pool is that it becomes difficult to mak=
e
> 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:
>
>        =E2=80=A2 Watches are ordered with respect to other events, other =
watches,
> and asynchronous replies. The ZooKeeper client libraries ensures that
> everything is dispatched in order.
>        =E2=80=A2 A client will see a watch event for a znode it is watchi=
ng before
> seeing the new data that corresponds to that znode.
>        =E2=80=A2 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 again=
st
> 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 th=
is
> at the client level (rather than for each individual watcher class I
> implement) is a cleaner approach IMO.
> >
> > Thoughts?
> >
> > -Martin
>
>

--485b397dcd9957d95b04aa92f9ce--