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? > > - 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 >>> >>> >
