[ https://issues.apache.org/jira/browse/ARIES-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16970968#comment-16970968 ]
ASF subversion and git services commented on ARIES-1941: -------------------------------------------------------- Commit f14ba9d7a13eedbb5a9195e87a6e8f9417de3369 in aries-rsa's branch refs/heads/master from Arnoud Glimmerveen [ https://gitbox.apache.org/repos/asf?p=aries-rsa.git;h=f14ba9d ] ARIES-1941 Addressed synchronization inconsistency in (using) MultiMap (#31) * ARIES-1941 Addressed synchronization inconsistency in (using) MultiMap Changed the approach to MultiMap to have all public method thread-safe: using synchronized keyword *and* returning read-only *copies* when a Set is to be returned Changed the one case where a defensive copy was made. Note that this old approach was not thread-safe, as the copy-constructors' iterator could be 'tripped' by a concurrent modification. * With the change to regular HashMap, a defensive copy of keySet is needed. > Thread unsafe iteration of thread-safe MultiMap by TopologyManagerImport > ------------------------------------------------------------------------ > > Key: ARIES-1941 > URL: https://issues.apache.org/jira/browse/ARIES-1941 > Project: Aries > Issue Type: Bug > Components: Remote Service Admin > Affects Versions: rsa-1.14.0 > Reporter: Arnoud Glimmerveen > Assignee: Christian Schneider > Priority: Major > Fix For: rsa-1.15.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The TopologyMangerImport class uses the MultiMap (Map<String, Set<T>>). The > operations on the MultiMap itself are thread safe (by means of synchronised > keyword), however in some cases the Set<T> value is obtained and iterated > over, without holding the right mutex. As a result you may see > ConcurrentModificationExceptions. -- This message was sent by Atlassian Jira (v8.3.4#803005)