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 [[email protected]] Sent: Wednesday, August 08, 2012 12:00 PM To: [email protected] 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
