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?
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
> 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
> 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
> 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
> does not use ephemeral nodes and watches. ZOOKEEPER-321 is the jira if you
> want to track that. Hope this helps.
> 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
> > 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
> > instance. That gives you some scope but can keep the existence and use
> > ZK a secret.
> > You do have to worry a bit about how to initialize the ZK. For that
> > and for mocking purposes, it is pretty good practice to always inject the
> > instance into your classes a la spring.
> > On Fri, Jun 5, 2009 at 8:56 PM, Grant Ingersoll <gsing...@apache.org>
> >> 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?