accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: Post 1.5.3 and 1.6.3
Date Thu, 09 Jul 2015 04:07:23 GMT
If we do it early and are prepared to revert if we find we come into a
situation we cannot work around, then I'd be +1 to pursuing 0.9.2
(even though I was kinda happy I only needed to keep one version
installed now that we're not really making 1.5 releases any more).

Christopher L Tubbs II

On Wed, Jul 8, 2015 at 11:44 PM, Josh Elser <> wrote:
> 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
>>>>> the desired fixVersion)
>>>>> - Josh

View raw message