With Xid_v2 applied It's still hitting the error condition in DefaultISMLocking:136. Concurent threads are now deadlocking in DefaultISMLocking:67.
I've attached a screenshot detailing state when the initial error occurs. > -----Ursprüngliche Nachricht----- > Von: Claus Köll (JIRA) [mailto:j...@apache.org] > Gesendet: Donnerstag, 11. März 2010 16:13 > An: dev@jackrabbit.apache.org > Betreff: [jira] Updated: (JCR-2554) Deadlock inside XASession > on Weblogic > > > [ > https://issues.apache.org/jira/browse/JCR-2554?page=com.atlass > ian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Claus Köll updated JCR-2554: > ---------------------------- > > Attachment: Xid_v2.patch > > Now at first the Xid's will be checked and then the default > thread bound logic will work if we are not in a XAEnvironment. > > > Deadlock inside XASession on Weblogic > > ------------------------------------- > > > > Key: JCR-2554 > > URL: https://issues.apache.org/jira/browse/JCR-2554 > > Project: Jackrabbit Content Repository > > Issue Type: Bug > > Components: jackrabbit-core > > Affects Versions: 1.6.1, 2.0.0 > > Environment: Weblogic 9.2 > > Reporter: Robert Sauer > > Assignee: Claus Köll > > Priority: Critical > > Attachments: ConcurrentReaders.java, > > jr-core-xid-aware-ism-locking1.patch, Xid.patch, Xid_v2.patch > > > > > > In one of our client deployments on WebLogic 9.2 we > observed JackRabbit sessions going stale in a load test. This > was observed against release 1.6.1 (to which we migrated due > to concurrency related issues JCR-2081 and JCR-2237). Same > effect with 2.0.0. > > > > I could finally reproduce this issue locally. And it seems > to boil down to WLS invoking the sequence of <prepare> ... > <release> ... <commit> on one XA session from multiple > threads, as it seems breaking assumptions of the thread-bound > java.util.concurrent-RWLock based DefaultISMLocking class. > > Effectively the setActiveXid(..) method on > DefaultISMLocking$RWLock fails as the old active XID was not > yet cleared. With the result of more and more sessions > deadlocking in below's invocation stack. > > {code} > > "[ACTIVE] ExecuteThread: '27' for queue: 'weblogic.kernel.Default > > (self-tuning)'" daemon prio=1 tid=0x33fc3ec0 nid=0x2324 in > > Object.wait() [0x2156a000..0x2156beb0] at > java.lang.Object.wait(Native > > Method) - waiting on <0x68a54698> (a > > > EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterL > > ock) at java.lang.Object.wait(Object.java:474) at > > > EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterL > > ock.acquire(Unknown Source) - locked <0x68a54698> (a > > > EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterL > > ock) at > > > org.apache.jackrabbit.core.state.DefaultISMLocking$1.<init>(DefaultISM > > Locking.java:64) at > > > org.apache.jackrabbit.core.state.DefaultISMLocking.acquireWriteLock(De > > faultISMLocking.java:61) at > > > org.apache.jackrabbit.core.version.AbstractVersionManager.acquireWrite > > Lock(AbstractVersionManager.java:146) at > > > org.apache.jackrabbit.core.version.XAVersionManager$1.prepare(XAVersio > > nManager.java:562) at > > > org.apache.jackrabbit.core.TransactionContext.prepare(TransactionConte > > xt.java:154) - locked <0x6dc2ad88> (a > > org.apache.jackrabbit.core.TransactionContext) at > > > org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:33 > > 1) at > > > org.apache.jackrabbit.jca.TransactionBoundXAResource.prepare(Transacti > > onBoundXAResource.java:68) at > > > weblogic.connector.security.layer.AdapterLayer.prepare(AdapterLayer.ja > > va:397) at > > > weblogic.connector.transaction.outbound.XAWrapper.prepare(XAWrapper.ja > > va:297) at > > > weblogic.transaction.internal.XAServerResourceInfo.prepare(XAServerRes > > ourceInfo.java:1276) at > > > weblogic.transaction.internal.XAServerResourceInfo.prepare(XAServerRes > > ourceInfo.java:499) at > > > weblogic.transaction.internal.ServerSCInfo$1.execute(ServerSCInfo.java > > :335) at weblogic.kernel.Kernel.executeIfIdle(Kernel.java:243) at > > > weblogic.transaction.internal.ServerSCInfo.startPrepare(ServerSCInfo.j > > ava:326) at > > > weblogic.transaction.internal.ServerTransactionImpl.localPrepare(Serve > > rTransactionImpl.java:2516) at > > > weblogic.transaction.internal.ServerTransactionImpl.globalPrepare(Serv > > erTransactionImpl.java:2211) at > > > weblogic.transaction.internal.ServerTransactionImpl.internalCommit(Ser > > verTransactionImpl.java:266) at > > > weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTrans > > actionImpl.java:227) at > > > weblogic.transaction.internal.TransactionManagerImpl.commit(Transactio > > nManagerImpl.java:283) at > > > org.springframework.transaction.jta.JtaTransactionManager.doCommit(Jta > > TransactionManager.java:1028) at > > > org.springframework.transaction.support.AbstractPlatformTransactionMan > > ager.processCommit(AbstractPlatformTransactionManager.java:709) at > > > org.springframework.transaction.support.AbstractPlatformTransactionMan > > ager.commit(AbstractPlatformTransactionManager.java:678) > > {code} > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > >
