[jira] [Updated] (ACCUMULO-4642) Remove SystemConfiguration.getInstance()
[ https://issues.apache.org/jira/browse/ACCUMULO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated ACCUMULO-4642: Attachment: ACCUMULO-4642-initial-draft.patch [^ACCUMULO-4642-initial-draft.patch] is a partial rough draft of removing SystemConfiguration.getInstance() that I abandoned (because it was a distraction) while working on ACCUMULO-4050. It may help somebody pick this up in the future, if somebody chooses to do so. > Remove SystemConfiguration.getInstance() > > > Key: ACCUMULO-4642 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4642 > Project: Accumulo > Issue Type: Improvement > Components: server-base >Reporter: Christopher Tubbs >Assignee: Christopher Tubbs >Priority: Minor > Attachments: ACCUMULO-4642-initial-draft.patch > > > 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 SystemConfiguration.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 SystemConfiguration.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 (v6.3.15#6346)
[jira] [Updated] (ACCUMULO-4642) Remove SystemConfiguration.getInstance()
[ https://issues.apache.org/jira/browse/ACCUMULO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated ACCUMULO-4642: Component/s: server-base > Remove SystemConfiguration.getInstance() > > > Key: ACCUMULO-4642 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4642 > Project: Accumulo > Issue Type: Improvement > Components: server-base >Reporter: Christopher Tubbs >Assignee: Christopher Tubbs >Priority: Minor > > 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 SystemConfiguration.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 SystemConfiguration.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 (v6.3.15#6346)
Accumulo-Master - Build # 2083 - Still Failing
The Apache Jenkins build system has built Accumulo-Master (build #2083) Status: Still Failing Check console output at https://builds.apache.org/job/Accumulo-Master/2083/ to view the results.
[jira] [Assigned] (ACCUMULO-4074) create user-configurable resource pools for different kinds of requests
[ https://issues.apache.org/jira/browse/ACCUMULO-4074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bella reassigned ACCUMULO-4074: Assignee: Keith Turner > create user-configurable resource pools for different kinds of requests > --- > > Key: ACCUMULO-4074 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4074 > Project: Accumulo > Issue Type: Improvement > Components: client, tserver >Reporter: Eric Newton >Assignee: Keith Turner > > Complex queries and iterator stacks can sometimes run for long periods of > time. During that time, access to resources for shorter, simpler lookups can > be blocked. Use separate resource pools to allow for simpler queries to be > able to run regardless. This same mechanism could be used for the metadata > and root tables, too. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
