[
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)
