May 2015 - jbossts-issues - Jboss List Archives

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

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2423: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/855 > 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)

8 years, 11 months

1
0
0 / 0

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

by Michael Musgrove (JIRA)

[ 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)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1339) Ensure that JTS can use the JDK ORB provided by WildFly

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1339?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1339: ----------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/jbosstm/narayana/pull/855 > Ensure that JTS can use the JDK ORB provided by WildFly > ------------------------------------------------------- > > Key: JBTM-1339 > URL: https://issues.jboss.org/browse/JBTM-1339 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > Original Estimate: 2 days > Remaining Estimate: 2 days > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1339) Ensure that JTS can use the JDK ORB provided by WildFly

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1339?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-1339: ---------------------------------------- wildfly is now running JTS just fine with the openjdk orb. To use it standalone (ie outside of JBoss Modules) we need to prepend the openjdk jar to the bootclasspath. I tried that on the jtax tests (via surefire argLine) and the tests run fine. My plan is to add another maven profile to run the surefire tests against openjdk-orb but the default will still be to use whatever comes with rt.jar > Ensure that JTS can use the JDK ORB provided by WildFly > ------------------------------------------------------- > > Key: JBTM-1339 > URL: https://issues.jboss.org/browse/JBTM-1339 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > Original Estimate: 2 days > Remaining Estimate: 2 days > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

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

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-2423: -------------------------------------- Summary: 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)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2422) Consider @Optimistic/@Pessimistic annotations on the Container

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-2422?page=com.atlassian.jira.plugin.... ] Mark Little commented on JBTM-2422: ----------------------------------- So the reason I haven't allowed this is because the semantics of the class/object and associated application may change dramatically between pessimistic and optimistic. The developer needs to understand the differences and someone who created their classes using optimistic, say, may not be the person who then uses them within a container years later that tries to override this annotation. I'd thought of allowing some annotations on classes/interfaces to override those of the container or vice versa in general, i.e., not just specifically for optimistic or pessimistic. For some it does make sense. For others not so much. Obviously we could control this within the annotation itself by saying whether or not it allows being overridden. > Consider @Optimistic/@Pessimistic annotations on the Container > -------------------------------------------------------------- > > Key: JBTM-2422 > URL: https://issues.jboss.org/browse/JBTM-2422 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: STM > Reporter: Tom Jenkinson > Assignee: Mark Little > > Would it make sense for the container to be optionally marked as @Optimistic and @Pessimistic thereby allowing an override of the behaviour requested by the object. The scenario I am considering is if you imagine a library of STM objects developed by some other team, could it be that the concurrency control of them is best defined by the app and the easiest way to do that might be via Container. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2422) Consider @Optimistic/@Pessimistic annotations on the Container

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-2422: ----------------------------------- Summary: Consider @Optimistic/@Pessimistic annotations on the Container Key: JBTM-2422 URL: https://issues.jboss.org/browse/JBTM-2422 Project: JBoss Transaction Manager Issue Type: Enhancement Components: STM Reporter: Tom Jenkinson Assignee: Mark Little Would it make sense for the container to be optionally marked as @Optimistic and @Pessimistic thereby allowing an override of the behaviour requested by the object. The scenario I am considering is if you imagine a library of STM objects developed by some other team, could it be that the concurrency control of them is best defined by the app and the easiest way to do that might be via Container. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2420) BlackTie hanging on all windows builds during btadmin: Transaction 0:ffff0a27a80e:-6a877d1b:555c3b97:8b has 1 heuristic participant(s)

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2420?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2420: ------------------------------------- http://albany.eng.hst.ams2.redhat.com/job/narayana-catelyn/920/ > BlackTie hanging on all windows builds during btadmin: Transaction 0:ffff0a27a80e:-6a877d1b:555c3b97:8b has 1 heuristic participant(s) > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2420 > URL: https://issues.jboss.org/browse/JBTM-2420 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, REST > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-catelyn/... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2417) Create CI pull request job for narayana.io

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2417?page=com.atlassian.jira.plugin.... ] Gytis Trikleris commented on JBTM-2417: --------------------------------------- I have this partially working. However, it might be good to update a web page in a way that it would work simply by opening index.html. Now, for example navigation will not work in such case. [~tomjenkinson], take a look under _site once you're on NCL VPN: http://172.17.130.4:8083/job/btny-pulls-narayana-io/jdk=jdk8.latest,label... > Create CI pull request job for narayana.io > ------------------------------------------ > > Key: JBTM-2417 > URL: https://issues.jboss.org/browse/JBTM-2417 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, Documentation > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2421) Provide some quickstarts for STM

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2421?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2421: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/quickstart/pull/140 > Provide some quickstarts for STM > -------------------------------- > > Key: JBTM-2421 > URL: https://issues.jboss.org/browse/JBTM-2421 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, STM > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > As part of my JBug I took the example from the documentation and produced a set of quickstarts that would be useful to contribute to the project. > The examples show: > 1. Pessimistic locking > 2. Optimistic locking > 3. Use of an STM object in a JTA transaction -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues May 2015