If a tl;dr helps here, Accumulo servers merge data from ZooKeeper with
the accumulo-site.xml file to determine the "configuration". When a user
updates the configuration, one (or potentially zero) servers will be
aware of this change (the one who actually performed the property update).
All other servers in the Accumulo cluster get an asynchronous update.
Presently, it is impossible to know when all servers have seen that
asynchronous update. Additionally, it is not technically infeasible to
implement this -- we just haven't done it.
Sean Busbey wrote:
Sure David. All of the comments on ACCUMULO-3176 prior to Christopher's
assertion go over the issue, where it impacts operations, and a current
mitigation.
https://issues.apache.org/jira/browse/ACCUMULO-3176
On Tue, Nov 25, 2014 at 12:29 PM, David Medinets<[email protected]>
wrote:
Sean, can you please provide a pointer to the discussion of race
conditions in property updates?
On Tue, Nov 25, 2014 at 1:10 PM, Sean Busbey<[email protected]> 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
--
Sean
