January 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1428) REST-AT quickstart test failed after transaction manager was not found

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1428?page=com.atlassian.jira.plugin.... ] Gytis Trikleris commented on JBTM-1428: --------------------------------------- It also happened for me once, when I did not have REST-AT war deployed. > REST-AT quickstart test failed after transaction manager was not found > ---------------------------------------------------------------------- > > Key: JBTM-1428 > URL: https://issues.jboss.org/browse/JBTM-1428 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Testing, TXFramework > Reporter: Gytis Trikleris > Assignee: Paul Robinson > Priority: Minor > Fix For: 5.0.0.M2 > > > See: http://172.17.131.2/job/btny-narayana-quickstarts-taconic/224 > {noformat} > Tests in error: > clientDrivenCommitTest(org.jboss.narayana.quickstarts.restat.IndirectTXManagementTest): Unexpected status. Expected 201 got 404 > clientDrivenRollbackTest(org.jboss.narayana.quickstarts.restat.IndirectTXManagementTest): Unexpected status. Expected 201 got 404 > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1428) REST-AT quickstart test failed after transaction manager was not found

by Gytis Trikleris (JIRA)

Gytis Trikleris created JBTM-1428: ------------------------------------- Summary: REST-AT quickstart test failed after transaction manager was not found Key: JBTM-1428 URL: https://issues.jboss.org/browse/JBTM-1428 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Testing, TXFramework Reporter: Gytis Trikleris Assignee: Paul Robinson Priority: Minor Fix For: 5.0.0.M2 See: http://172.17.131.2/job/btny-narayana-quickstarts-taconic/224 {noformat} Tests in error: clientDrivenCommitTest(org.jboss.narayana.quickstarts.restat.IndirectTXManagementTest): Unexpected status. Expected 201 got 404 clientDrivenRollbackTest(org.jboss.narayana.quickstarts.restat.IndirectTXManagementTest): Unexpected status. Expected 201 got 404 {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1356) Parallel prepare implementation does not handle LRCO correctly

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1356?page=com.atlassian.jira.plugin.... ] Work on JBTM-1356 stopped by Gytis Trikleris. > Parallel prepare implementation does not handle LRCO correctly > -------------------------------------------------------------- > > Key: JBTM-1356 > URL: https://issues.jboss.org/browse/JBTM-1356 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 5.0.0.M1 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Priority: Optional > Fix For: 5.0.0.M2 > > Original Estimate: 1 day > Time Spent: 4 hours, 30 minutes > Remaining Estimate: 0 minutes > > We implement LRCO by putting the 1PC aware resources at the end of the prepared list. Prepare is implemented by preparing each record in the prepared list and then stopping if any prepare fails. This means that if any 2PC aware resource fails then the 1PC resources are not get asked to prepare/commit. > The parallel prepare implementation prepares all participants in separate threads which is wrong - it should prepare 2PC aware participants first and if they vote commit should the 1PC resources be asked to commit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1356) Parallel prepare implementation does not handle LRCO correctly

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1356?page=com.atlassian.jira.plugin.... ] Gytis Trikleris logged work on JBTM-1356: ----------------------------------------- Author: Gytis Trikleris Created on: 14/Jan/13 11:52 AM Start Date: 14/Jan/13 6:20 PM Worklog Time Spent: 4 hours, 30 minutes Issue Time Tracking ------------------- Remaining Estimate: 0 minutes (was: 1 day) Time Spent: 4 hours, 30 minutes Worklog Id: (was: 12428398) > Parallel prepare implementation does not handle LRCO correctly > -------------------------------------------------------------- > > Key: JBTM-1356 > URL: https://issues.jboss.org/browse/JBTM-1356 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 5.0.0.M1 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Priority: Optional > Fix For: 5.0.0.M2 > > Original Estimate: 1 day > Time Spent: 4 hours, 30 minutes > Remaining Estimate: 0 minutes > > We implement LRCO by putting the 1PC aware resources at the end of the prepared list. Prepare is implemented by preparing each record in the prepared list and then stopping if any prepare fails. This means that if any 2PC aware resource fails then the 1PC resources are not get asked to prepare/commit. > The parallel prepare implementation prepares all participants in separate threads which is wrong - it should prepare 2PC aware participants first and if they vote commit should the 1PC resources be asked to commit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1356) Parallel prepare implementation does not handle LRCO correctly

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1356?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-1356: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/202 > Parallel prepare implementation does not handle LRCO correctly > -------------------------------------------------------------- > > Key: JBTM-1356 > URL: https://issues.jboss.org/browse/JBTM-1356 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 5.0.0.M1 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Priority: Optional > Fix For: 5.0.0.M2 > > Original Estimate: 1 day > Time Spent: 4 hours, 30 minutes > Remaining Estimate: 0 minutes > > We implement LRCO by putting the 1PC aware resources at the end of the prepared list. Prepare is implemented by preparing each record in the prepared list and then stopping if any prepare fails. This means that if any 2PC aware resource fails then the 1PC resources are not get asked to prepare/commit. > The parallel prepare implementation prepares all participants in separate threads which is wrong - it should prepare 2PC aware participants first and if they vote commit should the 1PC resources be asked to commit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1411) ExtendedUnitTest.testRememberAction test failed because of NullPointerException

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1411?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reopened JBTM-1411: --------------------------------- > ExtendedUnitTest.testRememberAction test failed because of NullPointerException > ------------------------------------------------------------------------------- > > Key: JBTM-1411 > URL: https://issues.jboss.org/browse/JBTM-1411 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Testing, Transaction Core > Reporter: Gytis Trikleris > Assignee: Mark Little > Priority: Minor > Fix For: 5.0.0.M2 > > > See: http://172.17.131.2/job/jbossts-narayana-java7/125 > {noformat} > testRememberAction(com.hp.mwtests.ts.arjuna.statemanager.ExtendedUnitTest) Time elapsed: 1.39 sec <<< ERROR! > java.lang.NullPointerException > at com.arjuna.ats.arjuna.StateManager.rememberAction(StateManager.java:1270) > at com.hp.mwtests.ts.arjuna.resources.ExtendedObject.remember(ExtendedObject.java:87) > at com.hp.mwtests.ts.arjuna.statemanager.ExtendedUnitTest.testRememberAction(ExtendedUnitTest.java:148) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:78) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70) > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1411) ExtendedUnitTest.testRememberAction test failed because of NullPointerException

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1411?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-1411. --------------------------------- Resolution: Done > ExtendedUnitTest.testRememberAction test failed because of NullPointerException > ------------------------------------------------------------------------------- > > Key: JBTM-1411 > URL: https://issues.jboss.org/browse/JBTM-1411 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Testing, Transaction Core > Reporter: Gytis Trikleris > Assignee: Mark Little > Priority: Minor > Fix For: 5.0.0.M2 > > > See: http://172.17.131.2/job/jbossts-narayana-java7/125 > {noformat} > testRememberAction(com.hp.mwtests.ts.arjuna.statemanager.ExtendedUnitTest) Time elapsed: 1.39 sec <<< ERROR! > java.lang.NullPointerException > at com.arjuna.ats.arjuna.StateManager.rememberAction(StateManager.java:1270) > at com.hp.mwtests.ts.arjuna.resources.ExtendedObject.remember(ExtendedObject.java:87) > at com.hp.mwtests.ts.arjuna.statemanager.ExtendedUnitTest.testRememberAction(ExtendedUnitTest.java:148) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:78) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70) > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1336) DUPID detection for mysql in JTS mode does not work

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1336?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1336: -------------------------------- Fix Version/s: 5.0.0.M2 (was: 5.0.0.Final) > DUPID detection for mysql in JTS mode does not work > --------------------------------------------------- > > Key: JBTM-1336 > URL: https://issues.jboss.org/browse/JBTM-1336 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JTS > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.0.0.M2 > > Attachments: JBTM-1336.patch > > > Mysql does not send errorcode of XAException.XAER_DUPID, it sends 0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1356) Parallel prepare implementation does not handle LRCO correctly

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1356?page=com.atlassian.jira.plugin.... ] Work on JBTM-1356 started by Gytis Trikleris. > Parallel prepare implementation does not handle LRCO correctly > -------------------------------------------------------------- > > Key: JBTM-1356 > URL: https://issues.jboss.org/browse/JBTM-1356 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 5.0.0.M1 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Priority: Optional > Fix For: 5.0.0.M2 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > We implement LRCO by putting the 1PC aware resources at the end of the prepared list. Prepare is implemented by preparing each record in the prepared list and then stopping if any prepare fails. This means that if any 2PC aware resource fails then the 1PC resources are not get asked to prepare/commit. > The parallel prepare implementation prepares all participants in separate threads which is wrong - it should prepare 2PC aware participants first and if they vote commit should the 1PC resources be asked to commit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1383) LogStoreRecoveryTest hang

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1383?page=com.atlassian.jira.plugin.... ] Paul Robinson resolved JBTM-1383. --------------------------------- Resolution: Done > LogStoreRecoveryTest hang > ------------------------- > > Key: JBTM-1383 > URL: https://issues.jboss.org/browse/JBTM-1383 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Testing > Affects Versions: 5.0.0.M2 > Reporter: Michael Musgrove > Assignee: Paul Robinson > Fix For: 5.0.0.M2 > > Attachments: debug.25494 > > > http://172.17.131.2/job/jbossts-narayana-java6/123 job is stuck running LogStoreRecoveryTest -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues January 2013