[
https://issues.apache.org/jira/browse/ACCUMULO-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491870#comment-15491870
]
Josh Elser commented on ACCUMULO-4458:
--------------------------------------
bq. Right now I do extract all of the properties that are set
Ahh, apologies. I see this now. That leads me to wonder...
{code}
- String value = getXmlConfig().get(key);
+ /* Check the available-on-load configs and fall-back to the
possibly-update Configuration object. */
+ String value = staticConfigs.containsKey(key) ? staticConfigs.get(key) :
getXmlConfig().get(key);
{code}
Why can't this just be {{String value = staticConfigs.get(key)}} then? We know
that we have an explicit Accumulo config key already (given the method
signature). Am I missing something else?
bq. yeah, I was confused for awhile about what was going on with zooCache,
since it was static but was initialized in the constructor of the singleton.
Eventually decided it just must have been a mistake.
Makes sense, the bit-rot is real ;). HdfsZooInstance looks like it was always
like this (from initial import).
> lock contention around configuration settings impacts tablet server
> performance
> -------------------------------------------------------------------------------
>
> Key: ACCUMULO-4458
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4458
> Project: Accumulo
> Issue Type: Bug
> Components: tserver
> Affects Versions: 1.7.1, 1.8.0
> Reporter: Sean Busbey
> Assignee: Sean Busbey
> Priority: Critical
> Fix For: 1.7.3, 1.8.1, 2.0.0
>
> Attachments: ACCUMULO-4458-1.7.v1.patch
>
>
> While investigating a pretty severe performance regression comparing YCSB
> against 1.6 and 1.7, I found a fair bit of lock contention around getting
> configuration values. This was improved by ACCUMULO-4388, but various threads
> eventually all started contending on the configuration values expected from
> the site xml files.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
