accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: Post 1.5.3 and 1.6.3
Date Thu, 09 Jul 2015 03:44:31 GMT
Yeah, that's why I brought it up now. If we're going to do it, we should 
do it now and let the shake-down begin.

I know Hive has been on 0.9.2 for a while now, so I assume it's somewhat 
ok. I'm sure we'll be good testers :)

Christopher wrote:
> 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
> On Wed, Jul 8, 2015 at 6:25 PM, Josh Elser<>  wrote:
>> Also, might be worthwhile to look at thrift 0.9.2 for 1.8
>> For kerberos,
>> 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

View raw message