thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Reiss <>
Subject Re: Multiplexed, poolable transport
Date Thu, 26 Jun 2008 01:53:15 GMT
Sorry for the late response.  There are four separate issues here.

1/ Pooling and reusing connections.
2/ "virtual hosting" with service names prefixed to the message names.
3/ Timeout handling.
4/ Corruption detection and management.

With regards to #1, this is no different from any other code you would
use to maintain a pool of resources.  Take one out when you need it,
put it back when you don't.  I'll try to throw some code into contrib
that demonstrates this.

For #2, I'm of the opinion that this should be handled above the Thrift
level because it adds significant complexity to multiple components of
Thrift, it is not easy to add on a language-by-language basis, and I
don't think it can be done in a way that will be "right" for all users.

For #3, I would recommend just setting a send/recv timeout in the client
transport (C++ and PHP support this for sure).  If the request times out,
an exception will be thrown.

For #4, we depend on the TCP checksum to detect corruption at this point,
though a checksumming framed transport would be a nice feature.


Johan Stuyts wrote:
>> It seems to me that this is something that can be done completely
>> outside of Thrift (and we have done it at least once at Facebook).
> Could you write a wiki page about how you did it? Thanks.
>> Currently, it is not possible to use the same connection for multiple
>> simultaneous requests, but the concept of a client pool should still
> I do not want to have simultaneous requests over one connection, because I 
> assume building a transport that only supports serialized requests is much 
> easier. But as I said before I have no experience in writing protocols, so 
> I could be wrong.
>> work.  If this is done in a general way, I'd be happy to include it
>> in the base Thrift distribution.
> I am currently thinking in the direction of adding a TProtocol wrapper 
> that will add a service identifier prefix to each message name. On the 
> server side the message name will be split so the service and the function 
> can be looked up.
> I would like to have some input about what the best way would be to handle 
> error conditions: timeouts, corrupt streams, etc.
> --
> Kind regards,
> Johan Stuyts

View raw message