Hi Satish,
   My suggestion in the last email was just to prevent unnecessary
instantiation of zookeeper client objects. Creating a new zookeeper client
for different modules doing different things should be fine. I don't have
any recommemded approach for either of your suggestions. It really depends
on your encapsulation, application API's and your usage model.


On 6/7/09 4:58 PM, "Satish Bhatti" <cthd2...@gmail.com> wrote:

> Hey Mahadev,
> I had a question about that.  In my application I am using ZooKeeper for
> several different unrelated purposes, e.g. to generate unique ids,  for
> distributed locks, and as a property store.  I have implemented generic
> black box classes that use ZooKeeper to provide that functionality, and when
> an object of one of those classes is instantiated it internally creates a
> ZooKeeper instance for its personal use.  So, for example, one of my apps
> has a property store and an id generator, and so it ends up using 2
> ZooKeeper client objects.  In principle I could create a single ZooKeeper
> client object and pass it in to the objects, so then I would only have a
> single ZooKeeper instance.  However, if receive
> a Watcher.Event.KeeperState.Expired event, a fresh ZooKeeper client instance
> has to be created.  If I were sharing the ZooKeeper instance, then somehow
> my objects would have to be notified that they should switch to using the
> new ZooKeeper instance.  That means somewhere in my app I would need to
> maintain a list of all objects using ZooKeeper.  Is this the recommended
> approach?  Is there some other more elegant way to do this?
> Satish
> On Sun, Jun 7, 2009 at 11:58 AM, Mahadev Konar <maha...@yahoo-inc.com>wrote:
>> HI Grant,
>>  I agree with Ted but just to elaborate a little more.
>>  Its good to have a single zookeeper instance connected to the server.
>> Zookeeper client are supposed to be long lived client and the expected
>> idiom
>> to use a zookeeper client is to have a  long lived single zookeeper client
>> per application instance. Most of the zookeeper recipes use zookeeper
>> session capabilities for implementing those recipes. So in that case, it
>> becomes necessary to have just a single client per app instance. Even if
>> you
>> don't plan to use zookeeper session capabilities (like ephemeral nodes and
>> watches) it would be good to just use a single zookeeper instance.
>> A zookeeper client if not being used in an application would just be
>> sending
>> pings every one third of the timeout values you set. We are working on an
>> opimization in 3.3 wherein we wont be even sending these pings if the
>> client
>> does not use ephemeral nodes and watches. ZOOKEEPER-321 is the jira if you
>> want to track that. Hope this helps.
>> mahadev
>> On 6/6/09 12:09 AM, "Ted Dunning" <ted.dunn...@gmail.com> wrote:
>>> It is a common idiom to have a single Zookeeper instance.  One reason for
>>> this is that it can be hard to keep track of which instance has which
>>> watches if you have lots of them around.
>>> Instantiating several Zookeeper structures and then discarding them also
>>> eliminates the utility of ephemeral philes.
>>> Watches and ephemerals are two of the key characteristics of ZK, so they
>> are
>>> quite a loss.
>>> That said, keeping a single zookeeper as a static in a single class isn't
>>> such a strange thing to do, especially if you can't imagine closing the
>> ZK
>>> instance.  That gives you some scope but can keep the existence and use
>> of
>>> ZK a secret.
>>> You do have to worry a bit about how to initialize the ZK.  For that
>> reason
>>> and for mocking purposes, it is pretty good practice to always inject the
>> ZK
>>> instance into your classes a la spring.
>>> On Fri, Jun 5, 2009 at 8:56 PM, Grant Ingersoll <gsing...@apache.org>
>> wrote:
>>>> What's the overhead of connecting to a Server?  In other words, if I'm
>> in a
>>>> multi-threaded web-app server environment, should I cache my ZooKeeper
>>>> instance and set a larger timeout value or should I just construct them
>> as I
>>>> need them?

Reply via email to