accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-4050) Serialize table configs into a single ZK node
Date Tue, 13 Sep 2016 02:24:21 GMT


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

* 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:
TableConfigurationSnapshot tableConf = ServerConfigurationFactory.getTableConfigurationSnapshot(T);

At this point, {{ServerConfigurationFactory}} constructs a new TableConfigurationSnapshot
something like this:

public getTableConfigurationSnapshot(Table T) {
  return new TableConfigurationSnapshot(tConfContainer.getSnapshot(), nConfContainer.getSnapshot());

Now, {{TableConfigurationSnapshot}} provides an immutable hierarchical view the chain of snapshots.

> Serialize table configs into a single ZK node
> ---------------------------------------------
>                 Key: ACCUMULO-4050
>                 URL:
>             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

View raw message