You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Claus Köll (JIRA)" <ji...@apache.org> on 2008/06/26 10:56:45 UTC
[jira] Commented: (JCR-1334) Deadlock with XA enabled
[ https://issues.apache.org/jira/browse/JCR-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608345#action_12608345 ]
Claus Köll commented on JCR-1334:
---------------------------------
hi marcel,
as written before your patch works fine but i found that in some really rarely situations (that i can not reproduce) a deadlock has still occured.
I have modified your patch as follows to find out when a readlock will be aquired with a wrong active_writer
public Sync readLock() {
if (activeWriter_ != null && activeWriter_ != Thread.currentThread()) {
System.out.println("Jackrabbit - PatchedDefaultISMLocking: ActiveWriter Thread not the same for readLock() ! ActiveWriter is " + activeWriter_.getName()
+ "CurrentThread is " + Thread.currentThread().getName());
Throwable throwable = new Throwable();
throwable.fillInStackTrace();
throwable.printStackTrace();
activeWriter_ = Thread.currentThread();
}
return super.readLock();
}
i know to set the activewriter to the current Thread is no good idea but i want to know where the issues comes from and my application should not
run into a deadlock.
And here is the stacktrace
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R java.lang.Throwable
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at org.apache.jackrabbit.core.state.PatchedDefaultISMLocking$RWLock.readLock(PatchedDefaultISMLocking.java(Compiled Code))
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at org.apache.jackrabbit.core.state.PatchedDefaultISMLocking.acquireReadLock(PatchedDefaultISMLocking.java(Inlined Compiled Code))
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java(Inlined Compiled Code))
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java(Compiled Code))
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at org.apache.jackrabbit.core.state.ChangeLog.undo(ChangeLog.java:330)
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at org.apache.jackrabbit.core.state.XAItemStateManager.rollback(XAItemStateManager.java:182)
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at org.apache.jackrabbit.core.TransactionContext.rollback(TransactionContext.java:224)
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at org.apache.jackrabbit.core.XASessionImpl.rollback(XASessionImpl.java:352)
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at org.apache.jackrabbit.jca.TransactionBoundXAResource.rollback(TransactionBoundXAResource.java:76)
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at com.ibm.ejs.j2c.XATransactionWrapper.rollback(XATransactionWrapper.java:1148)
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at com.ibm.ws.Transaction.JTA.JTAXAResourceImpl.rollback(JTAXAResourceImpl.java:347)
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at com.ibm.ws.Transaction.JTA.RegisteredResources.distributeOutcome(RegisteredResources.java:1085)
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at com.ibm.ws.Transaction.JTA.RegisteredResources.distributeRollback(RegisteredResources.java:1908)
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at com.ibm.ws.Transaction.JTA.TransactionImpl.internalRollback(TransactionImpl.java:1511)
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at com.ibm.ws.Transaction.JTS.TransactionWrapper.rollback(TransactionWrapper.java:591)
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at com.ibm.ws.Transaction.JTS.WSCoordinatorImpl.rollback(WSCoordinatorImpl.java:163)
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at com.ibm.ws.Transaction.JTS._WSCoordinatorImplBase._invoke(Unknown Source)
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java(Compiled Code))
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java(Compiled Code))
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at com.ibm.rmi.iiop.ORB.process(ORB.java(Compiled Code))
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at com.ibm.CORBA.iiop.ORB.process(ORB.java(Compiled Code))
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at com.ibm.rmi.iiop.Connection.doWork(Connection.java(Compiled Code))
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java(Compiled Code))
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java(Compiled Code))
[25.06.08 18:13:36:019 CEST] 1ea9f0d9 SystemErr R at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:937)
As i can see Websphere has a ThreadPool for the XA Communication and so it is not guaranteed that the same thread that holds the writelock comes to get a redlock.
I don't know how to solve that problem
BR,
claus
> Deadlock with XA enabled
> ------------------------
>
> Key: JCR-1334
> URL: https://issues.apache.org/jira/browse/JCR-1334
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core, jackrabbit-jca
> Affects Versions: 1.4
> Environment: WebSphere Application Server 5.1
> Reporter: Claus Köll
> Priority: Critical
> Attachments: javacore.20080121.132210.2524.txt, lock_output.txt, PatchedDefaultISMLocking.java, PatchedDefaultISMLocking_2.java, Stacktrace.txt
>
>
> Since we have configured a j2c resource adapter any modification to the repository ends
> with a deadlock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.