thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Utku Can Topçu <u...@topcu.gen.tr>
Subject Re: Pattern for Java Thrift Client/Connection pooling
Date Thu, 09 Sep 2010 22:52:35 GMT
Thank you Bryan,

I was basically thinking of using the Commons GenericObjectPool, thank you
for confirming my ideas on it.

However I'm not sure how to design the pool.
It's true that, I'll have some dead connections eventually and they need to
be either reopened or destroyed and replaced.

I guess validating the sanity of connections before using them seems to be a
wise decision. So, what should be the best way to check if a client object
is sane enough use; problem and the possible overhead occurs here.

And what about load balancing and other issues.
I guess Thrift needs at least a stable and production ready design pattern
proposal for connection pooling.

How can we make the client pool reliable enough to minimize overheads and
problems?

Regards,
Utku

On Tue, Sep 7, 2010 at 8:25 PM, Jeffrey DeCew <Jeffrey@decew.org> wrote:

> I agree, but be sure to consider your transport before going through this
> effort.
> I had this question when using the THttpClient transport, and found that
> adding the GenericObjectPool caused a 2x slowdown versus creating a new
> client for every call.  This is surely because the overhead associated with
> THttpClient is per-call, not per-connection like with TSocket, so the
> synchronization in the object pool became our bottleneck.
> --
> Jeff DeCew
>
>
> On Tue, Sep 7, 2010 at 10:11 AM, Bryan Duxbury <bryan@rapleaf.com> wrote:
>
> > You can use something like Commons GenericObjectPool to do this pretty
> > easily. You should definitely keep connections open rather than opening a
> > new one every time.
> >
> > On Mon, Sep 6, 2010 at 3:11 AM, Utku Can Topçu <utku@topcu.gen.tr>
> wrote:
> >
> > > Hi All,
> > >
> > > We're about to deploy a thrift service in production that will have a
> > huge
> > > load of "oneway" service calls.
> > > Right now we're now opening and closing a thrift connection/client for
> > each
> > > call that I can assume is not a good practice.
> > >
> > > Are there any projects or patterns involved in pooling and monitoring
> the
> > > thrift clients in Java?
> > >
> > > As far as I know the Hector project handles this issue for the
> > > CassandraClient, are there any good practices for a generalized thrift
> > > service?
> > >
> > > Regards,
> > > Utku
> > >
> >
>

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