[
https://issues.apache.org/jira/browse/ACCUMULO-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707582#comment-13707582
]
Keith Turner commented on ACCUMULO-1568:
----------------------------------------
[~vines], when I first implemented per-table config I arbitrarily decided to
put each config entry in a zookeeper node. Later this convention was followed
for system config stored in zookeeper. [~shickey] is currently working on
storing namespace configs in zookeeper.
The master did have some upgrade code in place for upgrading zookeeper. If I
remember correctly, it writes something after the zookeeper upgrade has run
successfully. Should the master die in the middle, it will just run the code
again.
> Make configuration changes Atomic
> ---------------------------------
>
> Key: ACCUMULO-1568
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1568
> Project: Accumulo
> Issue Type: Bug
> Reporter: Keith Turner
> Assignee: John Vines
> Fix For: 1.6.0
>
>
> I have not seen this issue, but its something I thought of. Assume the
> following happens.
> * iterators I1 ... I10 are configured to Table T1 at time 1
> * iterators NI1 ... NI10 are configured to Table T1 at time 2
> * compaction is reading iterator config and reads I1 ... I5 and NI4 ...
> NI9, a combination of the two iterator configurations w/o NI10, this could be
> really bad.
> Seems like this could be solved by use of Zookeeper transactions. The
> Accumulo API will need to change to allow setting many iterators or config
> settings at once.
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
