[
https://issues.apache.org/jira/browse/JCR-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483642
]
Jukka Zitting commented on JCR-798:
-----------------------------------
> event listeners registered by a session are already automatically
> unregistered on Session.logout().
Looking at the code it seems like the even listeners are unregistered only
after the item state and item managers have been disposed. That order should
probably at least be changed.
> the core issue here is that the same session is used by multiple
> threads (event dispatcher and application thread).
I don't think we can avoid that with the JCR observation design. At least the
event dispatcher and the application thread need to share the local namespace
mappings of the session.
I agree that it's an application problem if the event *listener* uses the same
session that was used to register it. Such a solution is almost always
incorrect, though I can see unwary developers easily falling into that trap.
Perhaps we should log a warning or even throw an exception if we detect a call
like Session.getItem() being issued from an event listener registered by the
same session?
> 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.
