accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Newton <>
Subject Re: Post 1.5.3 and 1.6.3
Date Wed, 15 Jul 2015 14:13:46 GMT
> This started making me think about making this clear for other components
> like FATE and RandomWalk.

Accumulo dev's have made some effort to extract Fate, Tracing, RandomWalk
and even ContinuousIngest, all to see the code copied (tracing, CI), with
little attribution, or ignored (RW, Fate). The effort to create independent
projects has largely been wasted.  Worse, it has led to convoluted
duplication within our own code base. For example, multiple copies of
zookeeper-related code.

I would rather do something like port RW to HBase, and adopt that version
for Accumulo, like we have for tracing.  Otherwise, I wouldn't bother
putting any effort into separating these modules with some abstract notion
that someone else might use it.


On Wed, Jul 8, 2015 at 3:43 PM, 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message