if java thrift were broken obviously the thrift clients would not work at all, since it needs to both read and write via thrift for that. from the thrift irc and mailing list I get the impression that lots of people use thrift/java.
serializing to a socket is not rocket science and the thrift source is straightforward. revising my earlier reply, although the thrift server classes would not be a good fit for us the lower-level stuff (TBinaryProtocol, TSocket) could replace what we are writing by hand just fine. I'm happy to write more tests to demonstrate that nothing breaks here. Code we are scared of touching is not good code. On Sat, Mar 28, 2009 at 10:40 AM, Prashant Malik <[email protected]> wrote: > 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? >> > >> >
