1:52 p.m.
Hi,
We are seeing occasional ConcurrentModificationException when accessing
certain portlets over wsrp. We already have a jira opened for this
https://jira.jboss.org/browse/GTNWSRP-84
The strange thing is that we have only been able to reproduce it on
linux machines, it doesn't appear to be reproducible on mac machines.
Has anyone seen issues like this before with respect to the jcr and
concurrent modifications? Or a jcr expert have a better idea to what the
issue is?
It looks like the wsrp jcr layer needs a bit of work to make it more
thread safe.
Caused by: java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at
org.exoplatform.services.jcr.impl.core.SessionDataManager.validate(SessionDataManager.java:1421)
at
org.exoplatform.services.jcr.impl.core.SessionDataManager.commit(SessionDataManager.java:1332)
at org.exoplatform.services.jcr.impl.core.ItemImpl.save(ItemImpl.java:681)
at org.exoplatform.services.jcr.impl.core.SessionImpl.save(SessionImpl.java:935)
at
org.gatein.portal.wsrp.state.JCRPersister$WSRPSessionLifeCycle.save(JCRPersister.java:191)
at org.chromattic.core.jcr.SessionWrapperImpl.save(SessionWrapperImpl.java:263)
at org.chromattic.core.DomainSessionImpl._save(DomainSessionImpl.java:583)
at org.chromattic.core.DomainSession.save(DomainSession.java:146)
at org.chromattic.core.api.ChromatticSessionImpl.save(ChromatticSessionImpl.java:223)
at org.gatein.portal.wsrp.state.JCRPersister.closeSession(JCRPersister.java:111)
at
org.gatein.portal.wsrp.state.consumer.JCRConsumerRegistry.update(JCRConsumerRegistry.java:116)
at
org.gatein.wsrp.consumer.registry.AbstractConsumerRegistry.updateProducerInfo(AbstractConsumerRegistry.java:249)
2:53 p.m.
On Nov 8, 2010, at 8:52 PM, Matt Wringe wrote:
Hi,
We are seeing occasional ConcurrentModificationException when accessing
certain portlets over wsrp. We already have a jira opened for this
https://jira.jboss.org/browse/GTNWSRP-84
The strange thing is that we have only been able to reproduce it on
linux machines, it doesn't appear to be reproducible on mac machines.
I've been trying to reproduce it on OS X with Chrome 9.0dev, FF 3.6, FF 4 and Safari
5.0.2 without being able to reproduce the issue.
Has anyone seen issues like this before with respect to the jcr and
concurrent modifications? Or a jcr expert have a better idea to what the
issue is?
More generally, it would help if someone with good knowledge or JCR and Chromattic could
review the code so that we're not missing anything obvious. The best solution would be
a pair programming kind of session but obviously, it's not really easy to set that up…
:/
It looks like the wsrp jcr layer needs a bit of work to make it more
thread safe.
> Caused by: java.util.ConcurrentModificationException
> at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
> at java.util.AbstractList$Itr.next(AbstractList.java:343)
> at
org.exoplatform.services.jcr.impl.core.SessionDataManager.validate(SessionDataManager.java:1421)
> at
org.exoplatform.services.jcr.impl.core.SessionDataManager.commit(SessionDataManager.java:1332)
> at org.exoplatform.services.jcr.impl.core.ItemImpl.save(ItemImpl.java:681)
> at org.exoplatform.services.jcr.impl.core.SessionImpl.save(SessionImpl.java:935)
> at
org.gatein.portal.wsrp.state.JCRPersister$WSRPSessionLifeCycle.save(JCRPersister.java:191)
> at org.chromattic.core.jcr.SessionWrapperImpl.save(SessionWrapperImpl.java:263)
> at org.chromattic.core.DomainSessionImpl._save(DomainSessionImpl.java:583)
> at org.chromattic.core.DomainSession.save(DomainSession.java:146)
> at
org.chromattic.core.api.ChromatticSessionImpl.save(ChromatticSessionImpl.java:223)
> at org.gatein.portal.wsrp.state.JCRPersister.closeSession(JCRPersister.java:111)
> at
org.gatein.portal.wsrp.state.consumer.JCRConsumerRegistry.update(JCRConsumerRegistry.java:116)
> at
org.gatein.wsrp.consumer.registry.AbstractConsumerRegistry.updateProducerInfo(AbstractConsumerRegistry.java:249)
Cordialement / Best,
Chris
==
Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein
Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm
3:07 p.m.
Hi,
a JCR session is not TS, you have to manage it by yourself. See below the
chapter related the Thread-Safety in the JSR 170
7.5 Thread-Safety Requirements
A content repository implementation is required to provide a
thread-safe implementation of all methods of
javax.jcr.Repository.
A content repository implementation is not required to provide
thread-safe implementations of other interfaces. As a consequence,
an application which concurrently or sequentially operates against
objects having affinity to a particular
Session through more than
one thread must provide synchronization sufficient to ensure no
more than one thread concurrently operates against that
Session
and changes made by one thread are visible to other threads.
On Mon, Nov 8, 2010 at 8:52 PM, Matt Wringe <mwringe(a)redhat.com> wrote:
Hi,
We are seeing occasional ConcurrentModificationException when accessing
certain portlets over wsrp. We already have a jira opened for this
https://jira.jboss.org/browse/GTNWSRP-84
The strange thing is that we have only been able to reproduce it on
linux machines, it doesn't appear to be reproducible on mac machines.
Has anyone seen issues like this before with respect to the jcr and
concurrent modifications? Or a jcr expert have a better idea to what the
issue is?
It looks like the wsrp jcr layer needs a bit of work to make it more
thread safe.
> Caused by: java.util.ConcurrentModificationException
> at
java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
> at java.util.AbstractList$Itr.next(AbstractList.java:343)
> at
org.exoplatform.services.jcr.impl.core.SessionDataManager.validate(SessionDataManager.java:1421)
> at
org.exoplatform.services.jcr.impl.core.SessionDataManager.commit(SessionDataManager.java:1332)
> at
org.exoplatform.services.jcr.impl.core.ItemImpl.save(ItemImpl.java:681)
> at
org.exoplatform.services.jcr.impl.core.SessionImpl.save(SessionImpl.java:935)
> at
org.gatein.portal.wsrp.state.JCRPersister$WSRPSessionLifeCycle.save(JCRPersister.java:191)
> at
org.chromattic.core.jcr.SessionWrapperImpl.save(SessionWrapperImpl.java:263)
> at
org.chromattic.core.DomainSessionImpl._save(DomainSessionImpl.java:583)
> at org.chromattic.core.DomainSession.save(DomainSession.java:146)
> at
org.chromattic.core.api.ChromatticSessionImpl.save(ChromatticSessionImpl.java:223)
> at
org.gatein.portal.wsrp.state.JCRPersister.closeSession(JCRPersister.java:111)
> at
org.gatein.portal.wsrp.state.consumer.JCRConsumerRegistry.update(JCRConsumerRegistry.java:116)
> at
org.gatein.wsrp.consumer.registry.AbstractConsumerRegistry.updateProducerInfo(AbstractConsumerRegistry.java:249)
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
--
Nicolas Filotto
Project Leader JCR
eXo Platform SAS
nicolas.filotto(a)exoplatform.com
+33 (0)6 31 32 92 19
3:30 p.m.
modify JCRPersister to have something that will help you to understand what's going on
such as :
public static class JCRPersister {
/** . */
private Exception owner;
/** . */
private final Lock lock = new ReentrantLock();
private void _save() {
// What save was doing before
}
public void save()
{
if (lock.tryLock()) {
owner = new Exception();
try {
_save();
} finally {
lock.unlock();
owner = null;
}
} else {
System.out.println("Caught attempt to double save, my stack
trace");
new Exception().printStackTrace(System.out);
System.out.println("Owner stack trace");
owner.printStackTrace(System.out);
}
}
}
On Nov 8, 2010, at 8:52 PM, Matt Wringe wrote:
Hi,
We are seeing occasional ConcurrentModificationException when accessing
certain portlets over wsrp. We already have a jira opened for this
https://jira.jboss.org/browse/GTNWSRP-84
The strange thing is that we have only been able to reproduce it on
linux machines, it doesn't appear to be reproducible on mac machines.
Has anyone seen issues like this before with respect to the jcr and
concurrent modifications? Or a jcr expert have a better idea to what the
issue is?
It looks like the wsrp jcr layer needs a bit of work to make it more
thread safe.
> Caused by: java.util.ConcurrentModificationException
> at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
> at java.util.AbstractList$Itr.next(AbstractList.java:343)
> at
org.exoplatform.services.jcr.impl.core.SessionDataManager.validate(SessionDataManager.java:1421)
> at
org.exoplatform.services.jcr.impl.core.SessionDataManager.commit(SessionDataManager.java:1332)
> at org.exoplatform.services.jcr.impl.core.ItemImpl.save(ItemImpl.java:681)
> at org.exoplatform.services.jcr.impl.core.SessionImpl.save(SessionImpl.java:935)
> at
org.gatein.portal.wsrp.state.JCRPersister$WSRPSessionLifeCycle.save(JCRPersister.java:191)
> at org.chromattic.core.jcr.SessionWrapperImpl.save(SessionWrapperImpl.java:263)
> at org.chromattic.core.DomainSessionImpl._save(DomainSessionImpl.java:583)
> at org.chromattic.core.DomainSession.save(DomainSession.java:146)
> at
org.chromattic.core.api.ChromatticSessionImpl.save(ChromatticSessionImpl.java:223)
> at org.gatein.portal.wsrp.state.JCRPersister.closeSession(JCRPersister.java:111)
> at
org.gatein.portal.wsrp.state.consumer.JCRConsumerRegistry.update(JCRConsumerRegistry.java:116)
> at
org.gatein.wsrp.consumer.registry.AbstractConsumerRegistry.updateProducerInfo(AbstractConsumerRegistry.java:249)
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
5188
days inactive
5188
days old
3 comments
4 participants
participants (4)
-
Christophe Laprun -
Julien Viet -
Matt Wringe -
Nicolas Filotto