You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Matt Benson (JIRA)" <ji...@apache.org> on 2011/02/11 00:46:57 UTC

[jira] Commented: (COLLECTIONS-330) ConcurrentModificationException using remove from the keySet the LRUMap

    [ https://issues.apache.org/jira/browse/COLLECTIONS-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993271#comment-12993271 ] 

Matt Benson commented on COLLECTIONS-330:
-----------------------------------------

Correct, but the contract of the map permits this, as iteration order is based on RU concerns.  Calling {{get()}} restructures the underlying data because the current entry becomes the LRU entry and so the map is modified.  The answer, therefore, is not to call get() when testing iterator behavior per the contract of the map.  Commit forthcoming.

> ConcurrentModificationException using remove from the keySet the LRUMap
> -----------------------------------------------------------------------
>
>                 Key: COLLECTIONS-330
>                 URL: https://issues.apache.org/jira/browse/COLLECTIONS-330
>             Project: Commons Collections
>          Issue Type: Bug
>          Components: Collection
>            Reporter: Joerg Schaible
>             Fix For: 4.0-beta-1
>
>
> Even if the access to a LRUMap is synced and the remove method of the iterator is used that has been returned from the keySet of the LRUMap, it is possible to get a ConcurrentModificationException. This does not happen for remove of the iterators returned by the entrySet or values of the LRUMap. See currently not executed unit test in TestLRUMap (marked as TODO for COLLECTION-3).

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira