Bumping thrift versions scares me... a lot... because of how terrible thrift has been about avoiding breakage and/or retaining functionality. It seems every time we bump to fix something we want fixed, we find many more things broken.
I'd be much more interested in moving to something a bit more reliable than Thrift... maybe Java serialization (heavy use of Externalizable) or protocol buffers with Netty. But, maybe that's something more for 2.0 (or later, since it seems like it'd be a huge effort). Even just moving off thrift for the network and leaving it in place for the serialization, might be a big improvement in stability. I'd be far less concerned about bumping thrift if it only affected the proxy. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Jul 8, 2015 at 6:25 PM, Josh Elser <josh.el...@gmail.com> wrote: > Also, might be worthwhile to look at thrift 0.9.2 for 1.8 > > For kerberos, https://issues.apache.org/jira/browse/THRIFT-2660. > > https://issues.apache.org/jira/browse/THRIFT-2274 might be a concern for us > too (would have to check). > > > Josh Elser wrote: >> >> Some thoughts myself... >> >> John Vines brought up to me privately the topic of separating out the >> RFile code from core. This started making me think about making this >> clear for other components like FATE and RandomWalk. These all have some >> level of separation, but they often get other things dropped into the >> same bucket (e.g. ZK-retry code in FATE, Accumulo implementation classes >> in RandomWalk). Maybe there are more things we could do. >> >> It would be nice to start trying to pull out these >> frameworks/sub-projects into discrete packages. I think it would help us >> with testing and proper separation of logic. Long term, maybe other >> projects would see the value and consider using/adopting them and grow >> into their own separately-versioned artifacts. It would be nice to start >> these efforts now to eventually reap the benefits. >> >> >> 2.0 and the new client API is a little scary now that we get another >> tick closer to it. I know it's been Christopher's brain-child so far >> (which is fine -- not meant to be taken in a negative context), but, if >> we really do want to adopt it, we should make a concerted effort to >> start integrating and reviewing it. Given how far away this seems, 1.8 >> and 1.9 could happen (or client API just gets targeted for a 3.0 -- >> numbers are just numbers). >> >> >> We have some decent script improvements for 1.8 already in (PID files >> _finally_). Would be nice to clean up the rest of the scripts too >> (notably the stop scripts need some love). >> >> >> Some other back-burner thoughts: better client API metrics, more >> server-side tracing instrumentation, Adam's iterator-stack collapsing >> perf ticket, keep tabs on HDFS tracing impl, keep tabs on HTrace's GUI >> work, finish the Accumulo monitor rewrite (aka REST server + servlet3). >> >> - Josh >> >> Josh Elser wrote: >>> >>> Thanks to the efforts spearheaded by Christopher and verified by >>> everyone else, we now have 1.5.3 and 1.6.3 releases! >>> >>> To keep the ball rolling, what's next? High level questions that come to >>> mind... >>> >>> * When do we do 1.7.1 and/or 1.8.0? >>> * What bug-fixes do we have outstanding for 1.7.1? >>> * What other minor improvements do people want for 1.8.0? >>> * Where does 2.0.0 stand? Should we make a bigger effort to getting the >>> new client API stuff Christopher had started into Apache? >>> >>> Feel free to brainstorm here and/or on JIRA (tagging relevant issues to >>> the desired fixVersion) >>> >>> - Josh
