Page History

...

1. Using a single hierarchical (or at least key-based) facade for accessing any global config.
2. Using strongly-typed sub-system configs instead of opaque Map-s: components would no longer deal with JSON parsing/writing, instead they would use properly annotated Java objects for config CRUD. Config objects would include versioning information (eg. lastModified timestamp).
3. Isolating access to the underlying config persistence layer: components would no longer directly interact with Zookeeper or files. Most likely the default implementation would continue using different ZK files per-subsystem in order to limit the complexity of file formats and to reduce the cost of notifications for unmodified parts of the configs.
4. Providing uniform way to register listeners for monitoring changes in specific configs: components would no longer need to interact with ZK watches, they would instead be notified about modified configs that they are interested in.

Hierarchical strongly-typed and versioned config

The API will offer a single facade interface (eg. ClusterConfig ) that will allow to retrieve and set strongly-typed instances of subsystem configurations.

Individual configurations need to be versioned (eg. timestamped). Since initially the primary backing store will be ZK we will get this information for free from zkVersion.

For example:

public interface VersionedConfig {
  // monotonically increasing version number
  long getVersion();
}

As an example, container-level plugins configuration could be defined in a PluginConfigs POJO and then it could be accessed like this:

ClusterConfig clusterConfig = ...
...
PluginConfigs containerPluginConfigs = clusterConfig.get("container/plugins", PluginConfigs.class);
... // modify the configuration
clusterConfig.set("container/plugins", containerPluginConfigs);

Change notifications

Components may register as listeners to the respective configuration path in order to receive notifications about updates:

public interface ClusterConfigListener<T extends VersionedConfig> {
  void onChange(T oldConfig, T newConfig);
}
...
clusterConfig.registerListener("container/plugins", listener);

Configuration sources

• solr.xml
• /clusterprops.json and other ZK files
• system properties
• environment variables

Initial configuration bootstrap

...