8:34 a.m.
[
https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin....
]
Michael Musgrove commented on JBTM-2423:
----------------------------------------
An example of the deadlock is in one of our unit tests (ResourceManagerFailureUnitTest)
where thread "main" takes the monitor 0x000000076ea03ba0 in shudown. The code
inside the openjdk-orb library then notfies "Thread-2" and then joins with it.
But "Thread-2" is blocked on the same monitor because it illegally tries to
access the orb after the run loop finishes:
{code}
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.25-b02 mixed mode):
"Thread-2" #12 daemon prio=5 os_prio=0 tid=0x00007fc5c8640000 nid=0x390d waiting
for monitor entry [0x00007fc599cb9000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.arjuna.orbportability.ORB.shutdown(ORB.java:252)
- waiting to lock <0x000000076ea03ba0> (a com.arjuna.orbportability.ORB)
at
com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.ORBRunner.run(ORBRunner.java:62)
"main" #1 prio=5 os_prio=0 tid=0x00007fc5c8008800 nid=0x38f9 in Object.wait()
[0x00007fc5cf022000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x000000076f26a3c0> (a
com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.ORBRunner)
at java.lang.Thread.join(Thread.java:1245)
- locked <0x000000076f26a3c0> (a
com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.ORBRunner)
at java.lang.Thread.join(Thread.java:1319)
at com.sun.corba.se.impl.orb.ORBImpl.shutdown(ORBImpl.java:1310)
- locked <0x000000076ede1c68> (a java.lang.Object)
at
com.arjuna.orbportability.internal.orbspecific.orb.implementations.ORBBase.shutdown(ORBBase.java:93)
- locked <0x000000076eb14828> (a
com.arjuna.orbportability.internal.orbspecific.javaidl.orb.implementations.javaidl_1_4)
at com.arjuna.orbportability.orb.core.ORB.shutdown(ORB.java:95)
at com.arjuna.orbportability.ORB.shutdown(ORB.java:295)
- locked <0x000000076ea03ba0> (a com.arjuna.orbportability.ORB)
at com.arjuna.orbportability.ORB.shutdown(ORB.java:252)
- locked <0x000000076ea03ba0> (a com.arjuna.orbportability.ORB)
at
com.hp.mwtests.ts.jta.jts.recovery.ResourceManagerFailureUnitTest.after(ResourceManagerFailureUnitTest.java:94)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95)
ORBRunner uses the orb after run() returns
------------------------------------------
Key: JBTM-2423
URL: https://issues.jboss.org/browse/JBTM-2423
Project: JBoss Transaction Manager
Issue Type: Bug
Reporter: Michael Musgrove
Assignee: Michael Musgrove
ORBRunner.java starts an orb using orb().run() but then performs operations on the orb
after the run() method returns. According to the CORBA spec this is invalid:
{quote}
Once an ORB has shutdown, only object reference management operations(duplicate,
release and is_nil) may be invoked on the ORB or any object reference obtained
from it.
{quote}
Note that when the orb.run() method returns the orb has shutdown because, for the run
method, the spec states:
{quote}
This operation will block until the ORB has completed the shutdown process,
{quote}
This issue has arisen because of a change made to our fork of the jdk orb: in the jdk orb
shutdown method we join with all the orb runners. This results in deadlock:
# com.arjuna.orbportability.ORB.shutdown is a synchronized method and it calls shutdown
on the jdk orb;
# shutdown on the jdk orb notifies the ORBRunner thread which now tries to call back into
a synchronized method of com.arjuna.orbportability.ORB but is blocked because the monitor
is held
# at this point the jdk orb shutdown would normally then return allowing the
the ORBRunner thread to make progress but a recent change now means that the jdk orb
shutdown method performs a join() on the various ORBRunner threads
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
3526
days inactive
3526
days old
jbossts-issues@lists.jboss.org
0 comments
1 participants
participants (1)
-
Michael Musgrove (JIRA)