[
https://issues.apache.org/jira/browse/JCR-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483623
]
Stefan Guggisberg commented on JCR-798:
---------------------------------------
martjin, thanks for sharing this.
> Consider the following scenario: Session A registers an
> EventListener B which uses A to process received events.
> Session A then logs out, and gets the Iterator in the
> LocalItemStateManager.dispose method. Then another thread
> modifies the repository and triggers the observation mechanism.
> EventListener B receives events, and processes them using
> Session A. This modifies the cache of Session A, and a CME is
> thrown.
this confirms my assumption. session A is actually used by 2
separate threads:
1. the thread that's logging out session A
2. the thread that is dispatching the events to the event listener
(which in turn is using session A aswell)
> I cannot find in the spec whether this is a valid use case of the JCR.
"7.5 Thread-Safety Requirements" states that you cannot assume Session
being thread-safe.
> I can image, however, that it is because otherwise each EventListener
> needs to create it's own session in order to to something with the events.
only if your EventListener interacts with the repository. that's just one, but
certainly not the only use case.
wrt your suggested fix (swapping the order of disposing the workspace/SISM):
while that would probably fix this issue i am somehow reluctant to apply it.
i am concerned that this could possibly cause new, more serious issues
since the order of those calls is quite delicate.
i am tempted to resolve this issue as "Won't fix" or "Invalid" since it's imo
caused
by improper session usage. wdyt?
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.
