thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Geyer" <>
Subject Re: Thrift server thread data and connection pooling
Date Mon, 11 Aug 2014 11:24:57 GMT

Hi Wilm,

I'd decouple the Thrift server from the poooled instances completely. 
Whenever an incoming request needs an instance, it pulls it out dynamically 
from the pool and pushes it back into the pool before the request handler 
completes. That gives you the freedom to increase/decrease the number of 
both independently as needed.

For the servers, there are nonblocking, threaded and threadpool-servers 
available, depending on what language you plan to use.

Have fun,

-----Urspr√ľngliche Nachricht----- 
From: Wilm Schumacher
Sent: Monday, August 11, 2014 2:58 AM
Subject: Thrift server thread data and connection pooling


I want to create a thrift service which uses an external library. To do
my work I need to creates an object. The object can by reused, however
the object is not thread safe. Furthermore the object creation is VERY
expensive. Round about 5 seconds 100% CPU per object. So creation on the
fly per call is a very bad idea :(. Fortunately the memory footprint of
the object is very small.

Thus I have to do something like connection pooling, pre-compute one
object per connection and reuse this object.

The question is: how? Or better: what would be the best plan to do that?

So I have some question about the internal implementation of concurrency
in the thrift library:

1.) Are the calls of the methods of the thrift handle simultaneously?
(well, of course I think so, but just for the sake of completeness) If
not, the problem actually does not arises.

2.) Is there something like connection pooling already intended? How can
I affect the number of created objects? If this is possible, and not
only one thrift handle is created, I could enlarge the number of handles
and use mutexes to block the calls. This would also be possible if I
create more than one process (but threads), because if I do not share
the object data the problem is avoided (fork vs. thread etc.). Is this
handled natively?

3.) However, another option would be the usage of one thrift handle,
pre-create a larger number of objects and use the idea of connection
pooling on the threads directly. However, for that purpose I have to
bind something like thread data to one thread. If this is possible
natively, how can I do that in thrift? Or are the threads created on the

4.) If none of the things above are a good idea or possible I could do
it the "hard way" and create a set of objects (from the library) and if
a method call occurs on the thrift handle, I pull a "free" object, block
it, do my stuff and release the resource when I'm done. So this would be
"semaphore style". However, this doesn't sound like a good plan because
I would mess around with the threads created by thrift.

Do I overthink the problem? Or do I miss an easy way?

Is this anyhow natively supported? Or do I have to do it by my own
"concurrency management"?

I guess, that I'm not the first one who encounter this problem. And this
is kind of a generic problem. So I assume that this topic is already
covered somehow. If you could point me to some documentation If would
appreciate your help.

Best wishes


View raw message