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<[email protected]> 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
http://gravatar.com/ctubbsii
