jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "CAREMOLI, Francois (ext.)" <francois.caremoli.prestata...@sfr.com>
Subject Problem while upgrading from Jackrabbit 1.6.2 to jackrabbit 2.2.9
Date Tue, 29 Nov 2011 18:29:43 GMT
Hello everyone,

    We were using our Jackrabbit content repository in version 1.6.2 on JBOSS 4.2.3. It was
configured as described on this page : http://wiki.apache.org/jackrabbit/JackrabbitOnJBoss.
Everything worked well, and we decided to upgrade to Jackrabbit v2.2.9. Configuration did
not change, and our content repository has behaved correctly, until we led some load testing.

At this point, the application bugs, and our content repository is no more available (until
a JBOSS reboot). The main stack shows this error log :

2011-11-29 17:57:17,193 WARN  [org.apache.jackrabbit.core.session.SessionState] : Attempt
to close session-username-59 while another thread is concurrently accessing this session.
Blocking until the other thread is finished using this session. Please review your code to
avoid concurrent use of a session.
java.lang.Exception: Stack trace of concurrent access to session-username-59
                at org.apache.jackrabbit.core.session.SessionState.close(SessionState.java:234)
                at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:888)
                at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:389)
                at org.apache.jackrabbit.jca.JCAManagedConnection.cleanup(JCAManagedConnection.java:170)
                at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.returnConnection(InternalManagedConnectionPool.java:339)
                at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.returnConnection(JBossManagedConnectionPool.java:704)
                at org.jboss.resource.connectionmanager.BaseConnectionManager2.returnManagedConnection(BaseConnectionManager2.java:369)
                at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:654)
                at org.apache.jackrabbit.jca.JCAManagedConnection.sendEvent(JCAManagedConnection.java:336)
                at org.apache.jackrabbit.jca.JCAManagedConnection.sendEvent(JCAManagedConnection.java:366)
                at org.apache.jackrabbit.jca.JCAManagedConnection.sendClosedEvent(JCAManagedConnection.java:373)
                at org.apache.jackrabbit.jca.JCAManagedConnection.closeHandle(JCAManagedConnection.java:226)
                at org.apache.jackrabbit.jca.JCAManagedConnection.closeHandles(JCAManagedConnection.java:431)
                at org.apache.jackrabbit.jca.TransactionBoundXAResource.end(TransactionBoundXAResource.java:58)
                at org.jboss.resource.connectionmanager.xa.JcaXAResourceWrapper.end(JcaXAResourceWrapper.java:58)
                at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelPrepare(XAResourceRecord.java:259)
                at com.arjuna.ats.arjuna.coordinator.BasicAction.doPrepare(BasicAction.java:2871)
                at com.arjuna.ats.arjuna.coordinator.BasicAction.doPrepare(BasicAction.java:2828)
                at com.arjuna.ats.arjuna.coordinator.BasicAction.prepare(BasicAction.java:2382)
                at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1783)
                at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:88)
                at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
                at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1389)
                at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135)
                at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
                at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:140)
                at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1028)
                at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:732)
                at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:701)
                at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
                at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
                at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
                at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
                at $Proxy223.findByReference(Unknown Source)

The problem is that no other thread is accessing the same  jcr session in our application
(we call javax.jcr.Repository.login(Credentials) for each method involving our content repository
). The findByReference method  (at stack end) is coded by ourself and works with another XA
managed transaction. I think that our session transaction is involved in a XA global transaction,
and that JCR is not very pleased that someone else accesses its session (or transaction),
when XA rollbacks or commits its transaction. We tried to remove <xa-transaction/> from
our datasource configuration file, but it prevents us from using the repository....

Thanks in advance for your help,
Fran├žois Caremoli

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message