jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Robert.Sa...@sungard.com>
Subject AW: [jira] Updated: (JCR-2554) Deadlock inside XASession on Weblogic
Date Thu, 11 Mar 2010 16:09:28 GMT
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:jira@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.
> 
> 
> 


Mime
View raw message