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