thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wilm Schumacher <wilm.schumac...@cawoom.com>
Subject sending large byte objects via thrift
Date Wed, 12 Nov 2014 09:02:57 GMT
Hi,

I always read that thrift is not optimized for sending large byte
objects (e.g. files) via thrift and that e.g. http should be used instead.

However, I want to discuss the use case of connecting a frontend (e.g. a
web application) with a backend. This means that I have a handful of
connections per thrift server and both client and server are in the same
network, perhaps even the same rack. Thus network is only limited by the
network card chip

In this case I could send a byte object via thrift or create a e.g. http
server to recieve and send large obejctes via REST api.

But in this use case I do not understand why I shouldn't use thrift.
Whether I block a thread for a "http get" or a "thrift send" doesn't
make a difference, isn't it?

The advantage of the "thrift only" solution would be the simplicity. I
would need only one server, and one client per application server. Thus,
less code, less errors, less security issues etc..

The disadvantage of the "thrift only" solution would be the lack of
fancy http features, like compression. But compression wouldn't be a
good plan in this use case anyway, because bandwidth isn't the
bottleneck in this application of thrift and compression would block a
lot CPU.

Do I miss something? Is it perhaps the memory consumption of thrift for
large messages?

Best wishes

Wilm

Mime
View raw message