accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: [DISCUSS] MiniAccumuloCluster goals and approach
Date Wed, 26 Mar 2014 16:46:43 GMT
On 3/26/14, 9:33 AM, Keith Turner wrote:
> On Wed, Mar 26, 2014 at 12:26 PM, Josh Elser <> wrote:
>> On 3/26/14, 9:23 AM, Keith Turner wrote:
>>> That's my irk with it. The changes we made "hide" things for no other
>>>>> purpose than saying "we hid them". The next variant of a MAC is going
>>>>> have to re-architect the entire thing anyways (I'm doing this right now
>>>> and
>>>>> I'm overhauling it).
>>> There is a purpose.  Whats an alternative solution to the addition of
>>> "public List<LogWriter> getLogWriters()" to the MAC API?
>> Personally, I wouldn't have really cared if such a method was added to its
>> API.
> Why not?  It needlessly exposes a MAC implementation detail.  Java 7 offers
> a much better way to handle this situation and makes the need for these
> threads go away. As I said flushing the logs could be offered in the API in
> a much nicer way.  Thats one solution.

If it was needless as you claim, why was it added in the first place as 
a public method?

>>   If you want to re-write MAC all you have to support is the interface in
>>> minicluster, you are free to throw everything in minicluster.impl away.
>> No, not with the "interface" explicitly referencing MiniAccumuloC*Impl
>> internally, I can't. I do not see any way I can throw away the existing
>> impl given the API wrapper. Am I missing something?
> Does MiniAccumuloC*Impl leak from the minicluster package in some way?

I don't understand your question, so I'll restate my concern: the only 
implementation I can make that leverages MiniAccumuloC* is by extending 

Talking to John, he did present the possibility that MACI could be made 
into a common base, the current impl lifted to a new impl that isn't 
tied to specific details, and then that *should* work.

View raw message