accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Updated] (ACCUMULO-4642) Remove ServerConfiguration.getInstance()
Date Fri, 09 Jun 2017 22:16:18 GMT


Christopher Tubbs updated ACCUMULO-4642:
    Fix Version/s: 2.0.0

> Remove ServerConfiguration.getInstance()
> ----------------------------------------
>                 Key: ACCUMULO-4642
>                 URL:
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: server-base
>            Reporter: Christopher Tubbs
>            Assignee: Michael Miller
>            Priority: Minor
>             Fix For: 2.0.0
>         Attachments: ACCUMULO-4642-initial-draft.patch
>          Time Spent: 3h
>  Remaining Estimate: 0h
> In working with ACCUMULO-4050, I've realized that we need to do some internal refactoring
to get better control over HdfsZooInstance. This would enable better testing (because we could
inject a mock Instance more easily, and in more places). It would also allow us to reuse objects
without storing them statically in the JVM.
> Fully realizing this would involve a lot of work, moving the static state to a single
"context" object constructed on server startup, and shared (in part or in whole) as needed
throughout the runtime server code.
> However, I think we can get there incrementally, by starting with eliminating the ServerConfiguration.getInstance()
method. This causes SystemConfigurationFactory to also have a getInstance() method, and that
means that SystemConfigurationFactory is being used like the context object I describe, but
redundantly instead of AccumuloServerContext, or a server-specific subclass.
> Eliminating ServerConfiguration.getInstance() might involve an intermediate step of adding
Instance parameters to many methods which currently take only a SystemConfigurationFactory,
because components will not be able to get the Instance from that configuration factory any
longer. However, even this intermediate step will be progress towards moving to a single shared
context object, which provides access to both the Instance and the configuration factory.
> If we can move directly to the context object, that would probably be better, but it
would involve a lot more changes, in particular to the way the server code is initialized.
Then again, those changes might be good to prioritize anyway, because all our server components
seem to initialize differently, and it would be nice to rewrite their bootstrap code to follow
the same pattern.

This message was sent by Atlassian JIRA

View raw message