thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Slee <ms...@fb.com>
Subject RE: Using multi-threaded clients with Thrift
Date Wed, 08 Aug 2012 20:55:54 GMT
The Thrift transport layer is not thread-safe. It is essentially a wrapper on a socket.

You can't interleave writing things to a single socket from multiple threads without locking.
You also don't know what order the responses will come back in. Each thread is effectively
calling read(). To have this work in a multi-threaded environment would require another layer
of abstraction that parceled out responses on the socket and determined which data should
go to which thread. This would be less efficient in the common case of a single transport
per thread.

You certainly could build this functionality on top of the Thrift abstractions, but the base
layers are designed to be very lightweight and pretty closely mimic raw sockets.

>> If so, is the only way to make it work in a
multi-threaded environment is to use an independent connection (i.e.,
a new Transport) per thread?  That seems kind of wasteful and
inefficient.

In practice, assuming your number of threads is on the order of you number of cores, this
is not inefficient and additional sockets aren't very expensive. Having each thread own its
own socket obviates the need for locking around all accesses the shared socket resource, which
tends to be much more costly.

Another common design in a multi-threaded environment is to have a single networker thread
(or a low fixed number of them). This thread owns a transport, and the clients put in requests
to this thread to perform an operation and then block, waiting to receive a callback when
the operation they requested is complete.

Cheers,
mcslee
________________________________________
From: Akshat Aranya [aaranya@gmail.com]
Sent: Wednesday, August 08, 2012 12:00 PM
To: user@thrift.apache.org
Subject: Using multi-threaded clients with Thrift

Hi,

I'm trying to implement a Thrift client and server where both are
multi-threaded.  Things are working fine on the server side, but I'm
getting "out of sequence" errors on the client.  I looked through the
code a little bit, and I realized that a synchronous client can only
have one outstanding message, so it is not possible to have multiple
clients make simultaneous calls.  This problem happens even when each
thread has its own Client, but they share a Protocol.  Is my
assessment correct?  If so, is the only way to make it work in a
multi-threaded environment is to use an independent connection (i.e.,
a new Transport) per thread?  That seems kind of wasteful and
inefficient.

Thanks,
Akshat

Mime
View raw message