jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-798) ConcurrentModificationException during logout
Date Fri, 23 Mar 2007 15:59:32 GMT

    [ 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.


Mime
View raw message