On Fri, Sep 25, 2009 at 2:42 PM, Jake Luciani <[email protected]> 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 <[email protected]> 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" <[email protected]> > >> To: [email protected] > >> 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 <[email protected]> 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 > >>> > >>> > > >
