jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martijn Hendriks (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-798) ConcurrentModificationException during logout
Date Mon, 26 Mar 2007 19:25:32 GMT

    [ https://issues.apache.org/jira/browse/JCR-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484203
] 

Martijn Hendriks commented on JCR-798:
--------------------------------------

I am not familiar with the mechanics of remapping a namespace as Jukka mentioned, but isn't
it possible to apply a namespace remapping to two sessions and use one in the application
thread and one in the observation thread? If there is no usecase of two threads sharing a
session then I guess that the issue can indeed be resolved as "Won't fix" or "invalid" as
Stefan suggested.
I don't know whether trying to detect this kind of usage of sessions is worth the overhead.
Maybe the "nondeterministic detection" by the CME that is in place right now is enough?

Martijn

> 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