jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martijn Hendriks (JIRA)" <j...@apache.org>
Subject [jira] Created: (JCR-798) ConcurrentModificationException during logout
Date Mon, 19 Mar 2007 09:16:32 GMT
ConcurrentModificationException during logout
---------------------------------------------

                 Key: JCR-798
                 URL: https://issues.apache.org/jira/browse/JCR-798
             Project: Jackrabbit
          Issue Type: Bug
          Components: core
         Environment: Jackrabbit 1.2.1
            Reporter: Martijn Hendriks


We regularly get the following exception:

java.util.ConcurrentModificationException
        at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.checkMod(AbstractReferenceMap.java:761)
        at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.hasNext(AbstractReferenceMap.java:735)
        at java.util.Collections$UnmodifiableCollection$1.hasNext(Collections.java:1009)
        at java.util.Collections$UnmodifiableCollection$1.hasNext(Collections.java:1009)
        at org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:341)
        at org.apache.jackrabbit.core.WorkspaceImpl.dispose(WorkspaceImpl.java:170)
        at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1225)
        at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:379)

Two causes for this exception have been identified:

 (Taken from an email to the dev-list from Marcel Reutegger):
> - session A reads some items I
> - session B transiently removes items in I
> - session A logs out and starts to iterate over I in  LocalItemStateManager (LISM)
> - session B saves changes and removed items are evicted from A's LISM
> - session A gets concurrent modification exception

Another scenario is the following:
- Session A gets the iterator of the values of (the primary cache of) an ItemStateReferenceCache
in LocalItemStateManager.dispose.
- Session B then does something that triggers the CacheManager.
- The CacheManager then calls resizeAll, and evicts some items from the secondary cache of
the ItemStateReferenceCache of which the LocalItemStateManager has a values iterator.
- The garbage collector then runs and evicts the removed items also from the primary cache,
which effectively modifies the set over which is iterated.

Regards,

Martijn Hendriks

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message