[ 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