Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <28654246.1174665572520.JavaMail.jira@brutus>
Date: Fri, 23 Mar 2007 08:59:32 -0700 (PDT)
From: "Jukka Zitting (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-798) ConcurrentModificationException during
 logout
In-Reply-To: <18655878.1174295792346.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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