[
https://issues.apache.org/jira/browse/HADOOP-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13641880#comment-13641880
]
Jason Lowe commented on HADOOP-9504:
------------------------------------
Is this really the right fix? As I understand it, the problem was caused by
two or more threads racing in createMBeanInfo() and that's what clobbered a
HashMap causing an infinite loop on a subsequent get. I agree that making it a
ConcurrentHashMap will prevent the infinite loop, but will the resulting map
contain what we want? As is, it could contain a hodgepodge of puts from
different threads which seems bad.
createMBeanInfo() creates a fresh map upon each invocation, and I think the
real issue is that it makes the new map available to other threads via
metricsRateAttributeMod *before* the map has finished being initialized. I
think we should build the map into a local variable then advertise it only
after it has been completely filled in. That way metricsRateAttributeMod is
always referring to a consistent map that isn't being actively modified. The
only writes to the map are in createMBeanInfo(), and therefore we may not need
a ConcurrentHashMap in that case.
> create metricsRateAttributeMod with ConcurrentHashMap to avoid hashmap
> concurrent race
> --------------------------------------------------------------------------------------
>
> Key: HADOOP-9504
> URL: https://issues.apache.org/jira/browse/HADOOP-9504
> Project: Hadoop Common
> Issue Type: Bug
> Components: metrics
> Affects Versions: 3.0.0, 2.0.3-alpha
> Reporter: Liang Xie
> Assignee: Liang Xie
> Priority: Critical
> Attachments: HADOOP-9504.txt
>
>
> Please see HBASE-8416 for detail information.
> we need to take care of the synchronization for HashMap put(), otherwise it
> may lead to spin loop.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
