[
https://issues.apache.org/jira/browse/JCR-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483099
]
Stefan Guggisberg commented on JCR-798:
---------------------------------------
i don't think that the second scenario (i.e. garbage collector interfering
while iterating over ReferenceMap entries) is realistic since this should IMO
be taken care of by the commons-collections ReferenceMap class. since
ReferenceMap is being heavily used in jackrabbit's core we would see a lot more
issues like this if that wouldn't be the case.
i think that marcel's scenario and/or improper sharing of Session instances are
the most plausible explanations for this issue.
since i've never come across this issue myself i'd like to be able to reproduce
it in order to further analyze it.
martjin, could you perhaps provide a simple test-case?
cheers
stefan
> 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
> Assigned To: Stefan Guggisberg
> Fix For: 1.3
>
>
> 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.
