Github user ctubbsii commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/253#discussion_r119197637
--- Diff:
server/base/src/main/java/org/apache/accumulo/server/fs/PerTableVolumeChooser.java
---
@@ -67,86 +69,67 @@ public String choose(VolumeChooserEnvironment env,
String[] options) throws Accu
return chooser.choose(env, options);
}
- private VolumeChooser getVolumeChooserForTable(VolumeChooserEnvironment
env, ServerConfigurationFactory localConf) {
+ private VolumeChooser getVolumeChooserForTable(VolumeChooserEnvironment
env, ServerConfigurationFactory localConf) throws AccumuloException {
VolumeChooser chooser;
if (log.isTraceEnabled()) {
log.trace("Table id: " + env.getTableId());
}
final TableConfiguration tableConf =
localConf.getTableConfiguration(env.getTableId());
String clazz = tableConf.get(Property.TABLE_VOLUME_CHOOSER);
- if (null == clazz || clazz.isEmpty()) {
- chooser = fallbackVolumeChooser;
- } else {
- chooser = tableSpecificChooser.get(env.getTableId());
- if (chooser == null) {
- VolumeChooser temp =
Property.createTableInstanceFromPropertyName(tableConf,
Property.TABLE_VOLUME_CHOOSER, VolumeChooser.class, fallbackVolumeChooser);
- chooser = tableSpecificChooser.putIfAbsent(env.getTableId(), temp);
- if (chooser == null) {
- chooser = temp;
- // Otherwise, someone else beat us to initializing; use theirs.
- }
- } else if (!(chooser.getClass().getName().equals(clazz))) {
- if (log.isTraceEnabled()) {
- log.trace("change detected for table id: " + env.getTableId());
- }
- // the configuration for this table's chooser has been updated. In
the case of failure to instantiate we'll repeat here next call.
- // TODO stricter definition of when the updated property is used,
ref ACCUMULO-3412
- VolumeChooser temp =
Property.createTableInstanceFromPropertyName(tableConf,
Property.TABLE_VOLUME_CHOOSER, VolumeChooser.class, fallbackVolumeChooser);
- VolumeChooser last =
tableSpecificChooser.replace(env.getTableId(), temp);
- if (chooser.equals(last)) {
- chooser = temp;
- } else {
- // Someone else beat us to updating; use theirs.
- chooser = last;
- }
- }
- }
- return chooser;
+
+ return createVolumeChooser(clazz,
Property.TABLE_VOLUME_CHOOSER.getKey(), env.getTableId(), tableSpecificChooser);
}
- private VolumeChooser
getVolumeChooserForNonTable(VolumeChooserEnvironment env,
ServerConfigurationFactory localConf) {
+ private VolumeChooser
getVolumeChooserForNonTable(VolumeChooserEnvironment env,
ServerConfigurationFactory localConf) throws AccumuloException {
VolumeChooser chooser;
- final String customProperty =
Property.GENERAL_ARBITRARY_PROP_PREFIX.getKey() + env.getScope() +
".volume.chooser";
+ String property = VOLUME_CHOOSER_SCOPED_KEY(env.getScope());
if (log.isTraceEnabled()) {
log.trace("Scope: " + env.getScope());
- log.trace("Looking up property: " + customProperty);
+ log.trace("Looking up property: " + property);
}
AccumuloConfiguration systemConfiguration =
localConf.getConfiguration();
- String clazz = systemConfiguration.get(customProperty);
+ String clazz = systemConfiguration.get(property);
+ // only if the custom property is not set to we fallback to the table
volumn chooser setting
+ if (null == clazz) {
--- End diff --
@ivakegg Ah, yes, we should not be falling back to `table.volume.chooser`
for the non-table scopes. It should simply fail. However, since non-table
scopes are a new feature, it might cause things to fail if the non-table scope
delegate hasn't been specified. With that in mind, I can see how it might be
advantageous to consider a single property, rather than fail every time a new
scope is added to the chooser environment.
If we are sticking with the baked-in properties, perhaps:
`general.volume.chooser.logger` and `general.volume.chooser.unknown`. More
generally, `general.volume.chooser.<scope>`
If we want to move to custom properties only, perhaps:
`table.custom.volume.chooser` instead of `table.volume.chooser`. And, also the
scopes at `general.custom.volume.chooser.<scope>`?
We should also consider how other choosers get their table and non-table
configs, rather than just the `PerTableVolumeChooser`. For example, the
`PreferredVolumeChooser` I think gets its configs from
`table.custom.preferredVolumes`, but I'm not sure that makes sense when
handling non-table scopes.
One alternative to the separate properties, which might make it easier to
deal with the various scopes is that we could have more complex property types,
whose values include the class name and its configuration serialized. I haven't
thought too hard about what that would look like, but maybe something
structured, like JSON.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
