and if you aren't already, please use a branch in production (I created a -0.2 one for you) instead of running trunk directly. despite our best efforts some commits _will_ introduce bugs.
http://nedbatchelder.com/text/quicksvnbranch.html http://svnbook.red-bean.com/en/1.4/svn.branchmerge.html [i don't think asf is on svn 1.5 yet] On Sat, Mar 28, 2009 at 10:59 AM, Jonathan Ellis <[email protected]> wrote: > 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? >>> > >>> >> >
