accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: [VOTE] ACCUMULO-3176
Date Tue, 25 Nov 2014 19:16:54 GMT
Can I pick your brain some more? (also, I'm sorry if this is already 
addressed in the JIRA comments somewhere. I'm being lazy)

As we know, there is a larger problem of ensuring consistent 
configuration across all servers in the cluster. I don't think there is 
any contention here. There are ways we can do this, but no one has done 
it yet. That's the general problem, and, I believe, what you mean by the 
"underlying issue".

A subset of that problem is configuration updates for a table which is 
newly created. In my experience, this is often how I get bitten by this 
race condition -- I create a table, I updated some property (typically 
set an iterator/combiner/constraint), and then did some insert/scan 
before the tabletserver I communicated with got my property update.

I see this taking what is a technically difficult problem (assumption, 
since no one has done it yet) and making the problem partially better. 
In practice for me, this also means that how I often encountered this 
race condition is addressed.

I also don't see the changes that Jenna wrote as a blocker to 
implementing a "proper" blocking configuration update.

Can you clarify your level of concern with this change in: altering the 
public API (as a standalone change), implementing a partial fix for the 
larger problem, and the combination of the previous two points? It would 
be much appreciated.

Sean Busbey wrote:
> -1
> This change alters our public API while not solving the underlying issue of
> race conditions in property updates.
> On Tue, Nov 25, 2014 at 11:14 AM, Christopher<>  wrote:
>> Committers, this is a consensus vote on whether or not to include Jenna's
>> patch for ACCUMULO-3176 to the 1.7.0-SNAPSHOT (master) branch.
>> This patch improves the table creation API with the introduction of a
>> NewTableConfiguration object (similar to the pattern for
>> BatchWriterConfig), which allows us to be flexible on improving table
>> creation options in the future without creating many overloaded methods (as
>> the table creation API has been plagued by in the past). The main goal of
>> the patch is to allow table properties to be set on a table at the time of
>> creation, before any tablets are assigned, but it also lays the foundation
>> for future table creation improvements. Creating initial table properties
>> was already present in the RPC calls, but not exposed in the API. This can
>> support a number of use cases.
>> Since an objection was raised by Sean Busbey (and a veto expected), I've
>> initiated this vote in lieu of applying the patch under lazy consensus so
>> that any veto votes can be justified and addressed here.
>> Note: there are a few bugs in the Mock implementation of this that I've
>> fixed, as well as some minor deprecation warnings and javadoc improvements
>> I'm adding, please apply your vote under the assumption that those will be
>> fixed before it will be applied.
>> Please vote in accordance with the bylaws for consensus voting.
>> My vote is +1.
>> Thanks.
>> --
>> Christopher L Tubbs II

View raw message