You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Martijn Hendriks <ma...@gx.nl> on 2007/03/16 15:34:27 UTC
ConcurrenModificationException
Hi,
We regularly get the following exception, and I have currently no idea
what can cause this. It might be something in our own application that
is built upon Jackrabbit, but I don't know that for sure.
java.util.ConcurrentModificationException
at
org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySe
tIterator.checkMod(AbstractReferenceMap.java:761)
at
org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySe
tIterator.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(LocalItem
StateManager.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)
Has anyone seen this before?
Regards,
Martijn Hendriks
<GX> creative online development B.V.
t: 024 - 3888 261
f: 024 - 3888 621
e: martijnh@gx.nl
Wijchenseweg 111
6538 SW Nijmegen
http://www.gx.nl/
Re: ConcurrenModificationException
Posted by Marcel Reutegger <ma...@gmx.net>.
Hi Martijn,
Martijn Hendriks wrote:
> The second scenario that I sketched in my previous message is
> possible: I now can reproduce that values of an ItemStateReferenceMap
> are evicted by garbage collection during the iteration over that map
> in the LocalItemStateManager.dispose method (with Jackrabbit 1.2.1).
> On my local system, however, I did not get the ConcurrentModification
> exception (Java 5 doc says that it is thrown on a best-effort basis).
> Anyway, it seems like this is a possible cause of it.
thank you for sharing this info.
another scenario I can think of is the following:
- 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
regards
marcel
Re: ConcurrenModificationException
Posted by Martijn Hendriks <mh...@gmail.com>.
Hi,
The second scenario that I sketched in my previous message is
possible: I now can reproduce that values of an ItemStateReferenceMap
are evicted by garbage collection during the iteration over that map
in the LocalItemStateManager.dispose method (with Jackrabbit 1.2.1).
On my local system, however, I did not get the ConcurrentModification
exception (Java 5 doc says that it is thrown on a best-effort basis).
Anyway, it seems like this is a possible cause of it.
Regards,
Martijn
On 3/16/07, Martijn Hendriks <mh...@gmail.com> wrote:
> Hi Marcel,
>
> I am a bit reluctant on creating a JIRA issue because I don't know yet
> whether we are misusing jackrabbit (1.2.1) or not. I thought of two
> possible scenarios that might trigger the exception.
>
> The first scenario is two threads closing the same session. We create
> a new session for each thread, however.
>
> The second scenario is more complicated: Suppose that one thread gets
> the iterator (for the values of the ItemStateRefereceMap of an
> ItemStateReferenceCache) in the LocalItemStateManager.dispose method.
> Then another thread triggers the CacheManager.resizeAll method that
> effectively evicts items from the MLRUItemStateCache that serves as
> the secondary cache of that same ItemStateReferenceCache. Then some
> items in the ReferenceMap might be only weakly reachable, and are
> evicted. Could this happen? If so, then this might be what's going on.
> It would also explain why it is so badly reproducable (at least by
> me).
>
> Regards,
>
> Martijn
>
> On 3/16/07, Marcel Reutegger <ma...@gmx.net> wrote:
> > Hi Martijn,
> >
> > can you please create a jira issue report and provide relevant information like
> > the exact jackrabbit version you are using.
> >
> > thanks.
> >
> > regards
> > marcel
> >
> > Martijn Hendriks wrote:
> > > Hi,
> > >
> > > We regularly get the following exception, and I have currently no idea
> > > what can cause this. It might be something in our own application that
> > > is built upon Jackrabbit, but I don't know that for sure.
> > >
> > > java.util.ConcurrentModificationException
> > > at
> > > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySe
> > > tIterator.checkMod(AbstractReferenceMap.java:761)
> > > at
> > > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySe
> > > tIterator.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(LocalItem
> > > StateManager.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)
> > >
> > > Has anyone seen this before?
> > >
> > > Regards,
> > >
> > > Martijn Hendriks
> > > <GX> creative online development B.V.
> > >
> > > t: 024 - 3888 261
> > > f: 024 - 3888 621
> > > e: martijnh@gx.nl
> > >
> > > Wijchenseweg 111
> > > 6538 SW Nijmegen
> > > http://www.gx.nl/
> > >
> >
> >
>
Re: ConcurrenModificationException
Posted by Martijn Hendriks <mh...@gmail.com>.
Hi Marcel,
I am a bit reluctant on creating a JIRA issue because I don't know yet
whether we are misusing jackrabbit (1.2.1) or not. I thought of two
possible scenarios that might trigger the exception.
The first scenario is two threads closing the same session. We create
a new session for each thread, however.
The second scenario is more complicated: Suppose that one thread gets
the iterator (for the values of the ItemStateRefereceMap of an
ItemStateReferenceCache) in the LocalItemStateManager.dispose method.
Then another thread triggers the CacheManager.resizeAll method that
effectively evicts items from the MLRUItemStateCache that serves as
the secondary cache of that same ItemStateReferenceCache. Then some
items in the ReferenceMap might be only weakly reachable, and are
evicted. Could this happen? If so, then this might be what's going on.
It would also explain why it is so badly reproducable (at least by
me).
Regards,
Martijn
On 3/16/07, Marcel Reutegger <ma...@gmx.net> wrote:
> Hi Martijn,
>
> can you please create a jira issue report and provide relevant information like
> the exact jackrabbit version you are using.
>
> thanks.
>
> regards
> marcel
>
> Martijn Hendriks wrote:
> > Hi,
> >
> > We regularly get the following exception, and I have currently no idea
> > what can cause this. It might be something in our own application that
> > is built upon Jackrabbit, but I don't know that for sure.
> >
> > java.util.ConcurrentModificationException
> > at
> > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySe
> > tIterator.checkMod(AbstractReferenceMap.java:761)
> > at
> > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySe
> > tIterator.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(LocalItem
> > StateManager.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)
> >
> > Has anyone seen this before?
> >
> > Regards,
> >
> > Martijn Hendriks
> > <GX> creative online development B.V.
> >
> > t: 024 - 3888 261
> > f: 024 - 3888 621
> > e: martijnh@gx.nl
> >
> > Wijchenseweg 111
> > 6538 SW Nijmegen
> > http://www.gx.nl/
> >
>
>
Re: ConcurrenModificationException
Posted by Marcel Reutegger <ma...@gmx.net>.
Hi Martijn,
can you please create a jira issue report and provide relevant information like
the exact jackrabbit version you are using.
thanks.
regards
marcel
Martijn Hendriks wrote:
> Hi,
>
> We regularly get the following exception, and I have currently no idea
> what can cause this. It might be something in our own application that
> is built upon Jackrabbit, but I don't know that for sure.
>
> java.util.ConcurrentModificationException
> at
> org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySe
> tIterator.checkMod(AbstractReferenceMap.java:761)
> at
> org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySe
> tIterator.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(LocalItem
> StateManager.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)
>
> Has anyone seen this before?
>
> Regards,
>
> Martijn Hendriks
> <GX> creative online development B.V.
>
> t: 024 - 3888 261
> f: 024 - 3888 621
> e: martijnh@gx.nl
>
> Wijchenseweg 111
> 6538 SW Nijmegen
> http://www.gx.nl/
>