Hi. Thanks for the insights.
One of the reasons why I want to use Thrift is that the Thrift client/server seem to perform really really well. I've created simple cache which is forced to store only strings in a HashMap. It can perform 11 000 lookups per sec and get a total read throughput of about 50Mbyte/sec which is in the same league as if I was writing to a fast BTree or such sequentially. I have tested it with payloads from 1K up to 64K. My own http implementation does not perform this well damnit :) The only real constraint currently will be that the client need to encode/decode objects to a string representation. I initially made the cache store byte[] but switched to strings. Kindly //Marcus On Sat, Jun 7, 2008 at 1:47 PM, Johan Stuyts <[EMAIL PROTECTED]> wrote: > If you need to store heterogeneous collections of items, as you probably >> would like to in a distributed hashmap, you should just make the type of >> stored objects binary, and then handle the serialization/deserialization at >> the application level. This will make your hashmap implementation very >> general and simple, too. >> > > To me this would no longer be a Thrift solution. It requires that data is > explicitly serialized/deserialized, and, more importantly, the serialization > protocol is probably not implemented in the many languages that Thrift > supports. What if somebody wants to use your Thrift service and writes a > client program for it, only to find out that he cannot use the binary data > stored in the maps? If you decide to go this route, make sure you understand > the implications. > > If heterogeneous/polymorphic data (in containers or otherwise) is needed, I > suggest to use another RPC protocol, e.g. RMI or SOAP. > > -- > Kind regards, > > Johan Stuyts > -- Marcus Herou CTO and co-founder Tailsweep AB +46702561312 [EMAIL PROTECTED] http://www.tailsweep.com/ http://blogg.tailsweep.com/
