Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (nike.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.213.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type;
        b=V1xtKrQuAwEjXdXOWtzA3SAkvkVt+jq1I5PK7K34IC0V3DC0uuwPapcla1mHUS1m2z
         Z0+T2c+OQIN5aVQZH+sDV5UwLikn+kDEo5RXaq76v+Tit0Q7UQ3FYhqcOsWvFqSNf2ch
         dbJE4LDY90ebbwIhVQLkoKTKCkq2u2h8MdYJ0=
MIME-Version: 1.0
In-Reply-To: <AANLkTi=VYqeHY8ynUaCez8f6MsthEB1ShMxoyi5HS2rD@mail.gmail.com>
References: <24DE9291-603F-4F67-9A88-7363E8A125BA@gmail.com>
 <AANLkTik6Ua1hzTJtejPszVown44ANqBi85MSpLgsx9RW@mail.gmail.com>
 <AANLkTinxEDjb+b81pX03MGQ6EycGjLRm7avJmyb5aJSL@mail.gmail.com>
 <AANLkTi=VYqeHY8ynUaCez8f6MsthEB1ShMxoyi5HS2rD@mail.gmail.com>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Fri, 18 Feb 2011 11:40:39 -0800
Message-ID: <AANLkTin_JU=ng6BcgC+6Z_Ca4OTrxozH69HM6gbp5LQ5@mail.gmail.com>
Subject: Re: Question about sharing Zookeeper connections
To: user@zookeeper.apache.org
Cc: Peco Karayanev <pecomeister@gmail.com>
Content-Type: multipart/alternative; boundary=001e680f1688877757049c93b11d

--001e680f1688877757049c93b11d
Content-Type: text/plain; charset=UTF-8

Most applications just share a single connection for all uses of a single
class.  That might be viewed at the logically simplest extreme of a simple
connection pool.

Why did you need more than one connection for each kind of use?

On Fri, Feb 18, 2011 at 11:13 AM, Peco Karayanev <pecomeister@gmail.com>wrote:

> Hi,
> I slightly disagree with the priority for a "connection pool" for
> zookeeper.
> I had to implement a connection pool/reuse for a smaller environment (under
> 50 nodes). I have a toolchain that can be composed of parts, and each part
> needed some synchronization through zookeeper. So even on a smaller system
> these heavier toolchains started using a lot of physical sessions and
> connections. Hence the connection pool. Also from performance perspective
> establishing a TCP connection for every session adds latency overhead.
>
> Cheers
> Peco
>
>
> On Fri, Feb 18, 2011 at 11:58 AM, Benjamin Reed <ben.reed@gmail.com>
> wrote:
>
> > it does seem like a good idea to make multiple zk handles share a
> > connection, but as ted points out, they may have different timeouts,
> which
> > would make the sharing logic quite complicated. i think the
> implementation
> > might also be quite complicated. having said that, if someone could come
> up
> > with a simple and correct connection sharing implementation, we (or at
> > least
> > i) would be open to it.
> >
> > ben
> >
> > On Fri, Feb 18, 2011 at 9:31 AM, Ted Dunning <ted.dunning@gmail.com>
> > wrote:
> >
> > > On Fri, Feb 18, 2011 at 1:24 AM, YUNG-LIN HO <yunglin@gmail.com>
> wrote:
> > >
> > > > Because zookeeper clients will try to keep session alive by sending a
> > > ping
> > > > request every 2 seconds. If libraries in an application do not share
> > > > connections with each other, they would flood the zookeeper server
> with
> > > > unnecessary requests and drag down performance of the server.
> > > >
> > >
> > > Make sure that you have a valid reason to worry first.
> > >
> > > Do you have thousands of clients?
> > >
> > > If not, these keep-alives are likely to be undetectable, load-wise.
> > >
> > >
> > > > I am wondering is there any connection manager exists in the
> > > > Hadoop/Zookeeper project that helps users to share connections?
> > > >
> > >
> > > Yes.  Zookeeper.
> > >
> > > Just open a single connection and pass it around via a singleton of
> some
> > > kind or your favorite dependency injection technique.
> > >
> > > This isn't always a great idea since your disconnect and expiration
> > > strategies might differ between different uses in important ways.
> > >
> >
>

--001e680f1688877757049c93b11d--