[
https://issues.apache.org/jira/browse/ACCUMULO-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15486007#comment-15486007
]
Christopher Tubbs commented on ACCUMULO-4050:
---------------------------------------------
bq. ... And these containers could be merged together ... Or, would the
container be abstracting this hierarchy away?
The container abstracts the dynamic configuration for a single scope. The
snapshot represents the actual configuration pairs (at a single point in time),
providing all the normal conf getters from an immutable source.
It's not so much that the containers are merged... it's the snapshots they
*contain* are merged to form the view of the config for the caller.
Let me try to give an example using only part of the hierarchy, using table T,
and namespace N:
* T config is stored in {{/path/to/tables/T/conf}}
* N config is stored in {{/path/to/namespaces/N/conf}}
* {{tConfContainer = new TableConfContainer(T)}} is the "container" for T's
configuration
* {{nConfContainer = new NamespaceConfContainer(N)}} is the "container" for N's
configuration
When the caller needs the per-table configuration for T, it does something like:
{code:java}
TableConfigurationSnapshot tableConf =
ServerConfigurationFactory.getTableConfigurationSnapshot(T);
{code}
At this point, {{ServerConfigurationFactory}} constructs a new
TableConfigurationSnapshot something like this:
{code:java}
public getTableConfigurationSnapshot(Table T) {
return new TableConfigurationSnapshot(tConfContainer.getSnapshot(),
nConfContainer.getSnapshot());
}
{code}
Now, {{TableConfigurationSnapshot}} provides an immutable hierarchical view the
chain of snapshots.
> Serialize table configs into a single ZK node
> ---------------------------------------------
>
> Key: ACCUMULO-4050
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4050
> Project: Accumulo
> Issue Type: Sub-task
> Reporter: Christopher Tubbs
> Fix For: 2.0.0
>
>
> Use a single ZK node to store table configs, rather than split across
> multiple configs. This should make it easier to implement atomic changes to
> the configuration, and should simplify reading loading/saving configuration
> from/to ZooKeeper.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)