The java version of thrift is not very well tested and developed from what I know atleast it has no internal support from Facebook , thats why we only want to use it for the external API as it is required there.The Message semantics are very well understood by us and it is well tested code which has stood the test of time unless someone can prove to me that there are huge perf gains to be had by replacing it with something else I would not be able to measure the cost of changing this underlying essential and critical piece with anything else.
- Prashant On Sat, Mar 28, 2009 at 9:34 AM, Avinash Lakshman < [email protected]> wrote: > Why is it ad-hoc? And it uses a factory pattern and I don't think it hard > once you get a hang of it. Consumers of the system are not even going to > know about these details. Personally I am never a fan of fixing anything > that is not broken - in this case it has been working really well for us. > This is now just a matter of what one might prefer. Thrift is something > that > I would not like to see anywhere apart from the entry point. With regards > to > the using the string to lookup the handlers it was done because if you > don't > do that then you will have to resort to RPC style instead of message > passing > or find the handlers based on the kind of messages i.e if-else branching. > We > use non-blocking I/O for all our internal messaging and Thrift using > blocking I/O. There is big difference in throughput and also Thrift > non-blocking I/O from what I hear is horrendous in performance and > stability. My friend you don't have my vote for this :). > Avinash > > On Sat, Mar 28, 2009 at 8:11 AM, Jonathan Ellis <[email protected]> wrote: > > > we have a Message class that mostly represents a bunch of bytes (but > > sometimes does not, which in some cases causes bugs) and a bunch of > > other *Message classes that are not Message subclasses but generate > > Message objects (so you have the amusingly redundant Message message = > > readResponseMessage.makeReadResponseMessage() in places). > > > > I think we can replace these ad-hoc and tedious-to-write Message > > factories with generated thrift code. Thrift is good at this and > > efficient (currently our message identifiers are inefficient strings > > like "ROW-READ-VERB-HANDLER"). > > > > Any objections to investigating replacing the hand-coded messages with > > thrift? > > >
