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. --David 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 >
