thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joel Meyer <joel.me...@gmail.com>
Subject Re: Thrift client connection pooling?
Date Fri, 25 Sep 2009 23:45:04 GMT
On Fri, Sep 25, 2009 at 2:42 PM, Jake Luciani <jakers@gmail.com> wrote:

> For client side connection pooling, assuming you are already using a
> request
> thread pool, I would use thread specific storage to ensure each thread has
> it's own connection to the thrift service.


> On Fri, Sep 25, 2009 at 1:25 PM, Rush Manbert <rush@manbert.com> wrote:
>
> > Just because I'm curious...
> >
> > I understand the problem here, but I don't really see what thread
> specific
> > storage does to alleviate it, unless each thread was otherwise
> maintaining
> > multiple connections. What am I missing?
>

As Jake described, you're basically making your thread pool do double duty
as an object pool. It works well when your usage pattern for threads and
clients is similar; i.e. whenever I need a thread I also need a client.

Joel


> >
> > - Rush
> >
> >
> > On Sep 24, 2009, at 6:51 PM, Rob Slifka wrote:
> >
> >  Ah, so you're relying on pooling upstream?
> >>
> >> ----- Original Message -----
> >> From: "Jake Luciani" <jakers@gmail.com>
> >> To: thrift-user@incubator.apache.org
> >> Sent: Thursday, September 24, 2009 3:38:08 PM GMT -08:00 US/Canada
> Pacific
> >> Subject: Re: Thrift client connection pooling?
> >>
> >> I often use thread specific storage. 1 connection maintained per thread.
> >>
> >> Sent from my iPhone
> >>
> >> On Sep 24, 2009, at 5:56 PM, Rob Slifka <rslifka@sfu.ca> wrote:
> >>
> >>  Hi everyone,
> >>>
> >>> Just curious if/how anyone is doing client side connection pooling?
> >>>
> >>> For simplicity's sake, we're opening and closing connections on
> >>> demand. The trick is that under load you run out of native sockets
> >>> as a flurry of requests result in closed connections in TIME_WAIT.
> >>>
> >>> Any thoughts on this?
> >>>
> >>> Rob
> >>>
> >>>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message