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 <br...@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 <u...@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 > > >
