[jbossts-issues] [JBoss JIRA] (JBTM-2423) ORBRunner uses the orb after run() returns

Thu May 28 09:34:03 EDT 2015

    [ https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071944#comment-13071944 ] 

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)