You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Christopher Tubbs (Jira)" <ji...@apache.org> on 2020/03/06 03:43:00 UTC
[jira] [Resolved] (ACCUMULO-3411) Refactor VolumeManager
initialization so a ServerConfigurationFactory is available
[ https://issues.apache.org/jira/browse/ACCUMULO-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christopher Tubbs resolved ACCUMULO-3411.
-----------------------------------------
Resolution: Not A Problem
This is OBE. VolumeChoosers now have an env for stuff like this.
> Refactor VolumeManager initialization so a ServerConfigurationFactory is available
> ----------------------------------------------------------------------------------
>
> Key: ACCUMULO-3411
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3411
> Project: Accumulo
> Issue Type: Improvement
> Affects Versions: 1.7.0
> Reporter: Sean Busbey
> Priority: Minor
>
> VolumeChooser would be improved by an init call that provided a ServerConfigurationFactory. Currently, instances that need table configuration have to instantiate their own lazily.
> The initialization must be lazy because making their own instance requires an Instance object. instantiating an HDFSZooInstance requires a VolumeManager. Since the VolumeManager relies on their being a chooser, we get into a circular dependency.
> Either refactor VolumeManager instantiation so there is a ServerConfigurationFactory that can be passed to the VolumeChooser or do bootstrapping with a VolumeManager that doesn't use a VC to break the cycle.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)