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)