thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Taitelbaum <btait...@cs.oberlin.edu>
Subject Re: need client socket pool?
Date Fri, 22 May 2009 15:04:09 GMT
I tried for a while (in Ruby) to make some thread-safe client  
wrappers, but found that maintaining the synchronization logic (and  
other logic as well, for example at the time there were some issues  
with clearing out buffers after a failed call). I ended up just opting  
to create a new connection on every call, and for my purposes the  
slight performance hit was well worth the reliability gain.

If you use just a single client, then threadB will have to wait for  
threadA to finish, whereas using 2 clients will allow them to run in  
parallel, which should be a performance boost. If you want to get  
around this with just a single client, you can try to use the Twisted  
support for the python client (uses the reactor pattern), or make the  
calls to send_xxx and recv_xx yourself (synchronizing the calls, of  
course)

-Ben

On May 22, 2009, at 10:05 AM, Oscar wrote:

> Hi all,
>
> In our project we need call RPCs in different threads.
>
> //pseudo code
>
> void init()
> {
>  //initialize the transport and protocol
> }
>
>
> void threadA()
> {
> //call rpc a using the initialized client
> }
>
> void threadB()
> {
> //call rpc b using the initialized client
> }
>
>
> The above code has the race-condition problem.
>
> My question is: lock the client directly or make a client socket pool?
>
> What's your opinion?


Mime
View raw message