Thank both of you for your replies. That makes sense.
- Rush On Sep 25, 2009, at 4:45 PM, Joel Meyer wrote:
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 requestthread pool, I would use thread specific storage to ensure each thread hasit'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 threadspecificstorage does to alleviate it, unless each thread was otherwisemaintainingmultiple 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/CanadaPacificSubject: 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
smime.p7s
Description: S/MIME cryptographic signature
