On Wed, Mar 30, 2011 at 11:48 PM, Mark Slee <[email protected]> wrote: > Also will note that part of the reason TBufferedTransport isn't generally > necessary in Java is that by default your Java VM will typically already > have a stage of output buffering on its Socket implementation. Wrapping that > up in a TBufferedTransport would just burn up CPU/memory to no advantage. >
Works when you want programs in different languages to talk ? ( like a C++ app talks to Java app ? ) The buffering/streaming that the white paper describes isn't actually > beneficial in practice for typical moderate-payload RPC use cases, which is > what most people use Thrift for. The goal there was to not make it > *impossible* to do those things with Thrift, but if you're just issuing > basic RPCs, the framed transport makes things a lot easier to debug as each > payload is sent over the wire with a frame header containing its size. Well, lets assume I am building an Indexer which downloads stuff from many places and pushes it to Lucene. My downloader is in C++ and Lucene implementation is obviously in Java. I'd have multiple downloader programs running parallel and writing to multiple indexes. Do you think Buffered transport would fit this case better than Framed transport ? -- Regards Shrinath.M
