[
https://issues.apache.org/jira/browse/ACCUMULO-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491890#comment-15491890
]
Sean Busbey commented on ACCUMULO-4458:
---------------------------------------
{quote}
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?
{quote}
SiteConfiguration has a {{set}} method that allows folks to add additional
configuration keys to the underlying Hadoop Configuration object after
instantiation. Any calls to {{set}} won't be reflected in {{staticConfigs}},
because they're read-only after instantiation of SiteConfiguration so that
concurrent access can be safe.
> 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)
