April 2014 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2132) CMR Resources do not process XA exceptions correctly

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2132?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2132: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > CMR Resources do not process XA exceptions correctly > ---------------------------------------------------- > > Key: JBTM-2132 > URL: https://issues.jboss.org/browse/JBTM-2132 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTA > Affects Versions: 5.0.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.19, 5.0.2 > > > When committing a Commit Markable Resource any XA exception is treated as a TwoPhaseOutcome.FINISH_ERROR and the TM then goes on to commit the remaining (two phase aware) resources. The correct behaviour is to check the XA error code and if appropriate rollback the remaining resources. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2132) CMR Resources do not process XA exceptions correctly

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2132?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2132: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/634, https://github.com/jbosstm/narayana/pull/635 (was: https://github.com/jbosstm/narayana/pull/634) > CMR Resources do not process XA exceptions correctly > ---------------------------------------------------- > > Key: JBTM-2132 > URL: https://issues.jboss.org/browse/JBTM-2132 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTA > Affects Versions: 5.0.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.19, 5.0.2 > > > When committing a Commit Markable Resource any XA exception is treated as a TwoPhaseOutcome.FINISH_ERROR and the TM then goes on to commit the remaining (two phase aware) resources. The correct behaviour is to check the XA error code and if appropriate rollback the remaining resources. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2147) Transactions are leaked when XAResource misbehaves

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2147?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2147: ------------------------------------- Hi, I don't think there is much the transaction manager can do here. 1. The log message doesn't look to be coming out of Narayana code, i.e. I grepped the Narayana java code and could not find "Trying to start a new transaction when old is not complete" 2. Throwing RuntimeException out of XAResource::end is not a valid return code for an XAResource: http://docs.oracle.com/javaee/7/api/javax/transaction/xa/XAResource.html#..., int) I am going to reject this issue and suggest you raise a Jira for HornetQ. Thanks for your report, Tom > Transactions are leaked when XAResource misbehaves > -------------------------------------------------- > > Key: JBTM-2147 > URL: https://issues.jboss.org/browse/JBTM-2147 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTS > Affects Versions: 4.17.7 > Environment: jboss EAP 6.1.1 > Reporter: Koen Janssens > Assignee: Tom Jenkinson > > We have noticed that arjuna leaks transactions when something 'unexpected' happens during tx aborting. The transaction stays in 'aborting' state while it does notify TxLIsteners that the tx has ended. > This can be reproduced as follows: > * A TX is started and both a DB (last)resource and horntq (XA) resource get enlisted. The tx takes a long time and times out. > * Arjuna reaper thread notices the time out and starts a worker thread to cancel the TX. > * Before the worker thread can 'abort' the hornetq XA resource, the arjuna worker thread is interruped (txReaperCancelWaitPeriod expires) by arjuna > * Since the worker thread is interruped, the hornetq XA resource throws an 'HornetQInterruptedException' > * This unexpected exception causes arjuna to notify registered javax/transaction/Synchronization's (and return DB connection to the pool), without ending the Tx. > From then on, jboss logs are full of: > Trying to start a new transaction when old is not complete: Old: < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff40bab98c:1f71a485:5335ece7:3625a31, node_name=1, branch_uid=0:ffff40bab98c:1f71a485:5335ece7:3625bbc, subordinatenodename=null, eis_name=java:/XAOracleDS >, New < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff40bab98c:1f71a485:5335ece7:3641efc, node_name=1, branch_uid=0:ffff40bab98c:1f71a485:5335ece7:36420a1, subordinatenodename=null, eis_name=java:/XAOracleDS >, Flags 0 > Although the root cause is a misbehaving hornetq resource, I think arjuna should be a bit more resilient. > More background in https://access.redhat.com/support/cases/01061583/ -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2147) Transactions are leaked when XAResource misbehaves

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2147?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-2147. --------------------------------- Resolution: Rejected > Transactions are leaked when XAResource misbehaves > -------------------------------------------------- > > Key: JBTM-2147 > URL: https://issues.jboss.org/browse/JBTM-2147 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTS > Affects Versions: 4.17.7 > Environment: jboss EAP 6.1.1 > Reporter: Koen Janssens > Assignee: Tom Jenkinson > > We have noticed that arjuna leaks transactions when something 'unexpected' happens during tx aborting. The transaction stays in 'aborting' state while it does notify TxLIsteners that the tx has ended. > This can be reproduced as follows: > * A TX is started and both a DB (last)resource and horntq (XA) resource get enlisted. The tx takes a long time and times out. > * Arjuna reaper thread notices the time out and starts a worker thread to cancel the TX. > * Before the worker thread can 'abort' the hornetq XA resource, the arjuna worker thread is interruped (txReaperCancelWaitPeriod expires) by arjuna > * Since the worker thread is interruped, the hornetq XA resource throws an 'HornetQInterruptedException' > * This unexpected exception causes arjuna to notify registered javax/transaction/Synchronization's (and return DB connection to the pool), without ending the Tx. > From then on, jboss logs are full of: > Trying to start a new transaction when old is not complete: Old: < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff40bab98c:1f71a485:5335ece7:3625a31, node_name=1, branch_uid=0:ffff40bab98c:1f71a485:5335ece7:3625bbc, subordinatenodename=null, eis_name=java:/XAOracleDS >, New < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff40bab98c:1f71a485:5335ece7:3641efc, node_name=1, branch_uid=0:ffff40bab98c:1f71a485:5335ece7:36420a1, subordinatenodename=null, eis_name=java:/XAOracleDS >, Flags 0 > Although the root cause is a misbehaving hornetq resource, I think arjuna should be a bit more resilient. > More background in https://access.redhat.com/support/cases/01061583/ -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1369) Benchmark performance difference between JacORB and JDK ORB

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1369?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-1369: ---------------------------------- Assignee: Michael Musgrove (was: Gytis Trikleris) > Benchmark performance difference between JacORB and JDK ORB > ----------------------------------------------------------- > > Key: JBTM-1369 > URL: https://issues.jboss.org/browse/JBTM-1369 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JTS, Performance Testing > Affects Versions: 4.17.0 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.2 > > > JBTM-934 added support for the JDK orb to JTS. IOR sizes can range in size from 512 bytes to entirely unbounded, with the ORB being able to add arbitrary data within specific portions. Since the IOR is packed into transaction logs and if the IOR sizes are significantly different we may find that transaction throughput has been improved or degraded. We should run some benchmarks to see what the impact is. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2132) CMR Resources do not process XA exceptions correctly

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2132?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2132: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/634 > CMR Resources do not process XA exceptions correctly > ---------------------------------------------------- > > Key: JBTM-2132 > URL: https://issues.jboss.org/browse/JBTM-2132 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTA > Affects Versions: 5.0.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.19, 5.0.2 > > > When committing a Commit Markable Resource any XA exception is treated as a TwoPhaseOutcome.FINISH_ERROR and the TM then goes on to commit the remaining (two phase aware) resources. The correct behaviour is to check the XA error code and if appropriate rollback the remaining resources. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2076) Add security manager's permission checking in com.arjuna.webservices11.ServiceRegistry#getRegistry

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2076?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2076: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add security manager's permission checking in com.arjuna.webservices11.ServiceRegistry#getRegistry > -------------------------------------------------------------------------------------------------- > > Key: JBTM-2076 > URL: https://issues.jboss.org/browse/JBTM-2076 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.19, 5.0.2 > > > Permissions checking in public static methods is needed for Common Criteria certification. > Add something similar to this at the beginning of the method: > {code} > public static ServiceRegistry getRegistry() > { > SecurityManager sm = System.getSecurityManager(); > if (sm != null) { > sm.checkPermission(new RuntimePermission(ServiceRegistry.class.getName() + ".getRegistry")); > } > return REGISTRY ; > } > {code} -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2146) wsat-jta-multi_hop quickstart doesn't work

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2146?page=com.atlassian.jira.plugin.... ] Paul Robinson commented on JBTM-2146: ------------------------------------- Antonin, You can use the Narayana quickstarts with any recent EAP or WildFly release. The trick is to make sure you use the same tag of the quickstarts, as the version of Narayana inside the AS of your choosing. Here's how you do it: 1) Find out the version of Narayana: ls modules/system/layers/base/org/jboss/jts/main/jbossjts-jacorb-4.17.15.Final-redhat-4.jar 2) In this case it's 4.17.15.Final. 3) Checkout the 4.17.15.Final tag of the quickstarts from here: https://github.com/jbosstm/quickstart/releases We are very thorough about making sure our quickstarts work with EAP/WildFly. In-fact, we test them in CI for every commit we propose to the quickstarts or Narayana codebase. However, we only do this for matching versions, it's not feasible to do it for all the different permutations. > wsat-jta-multi_hop quickstart doesn't work > ------------------------------------------ > > Key: JBTM-2146 > URL: https://issues.jboss.org/browse/JBTM-2146 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Demonstrator, TxBridge, XTS > Environment: Windows 8.1 > Java 7 > Same for jboss-eap-6.1/jboss-eap-6.2/jboss-eap-6.3 > Reporter: Antonin Danek > Assignee: Gytis Trikleris > > When running the wsat-jta-multi_hop quick start, the test fails: > (despite standalone-xts.xml is provided exactly how the instructions say + 127.0.0.1:9990 is accessible using the browser) > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running org.jboss.narayana.quickstarts.wsat.jtabridge.fromjta.BridgeFromJTATest > IV 06, 2014 2:10:16 DOP. org.jboss.arquillian.container.impl.MapObject populate > WARNING: Configuration contain properties not supported by the backing object org.jboss.as.arquillian > .container.remote.RemoteContainerConfiguration > Unused property entries: {serverConfig=standalone-xts.xml} > Supported property names: [managementPort, username, managementAddress, managementProtocol, password] > .... > WARN: Cannot undeploy: test.war > org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper$ServerDeploymentException: j > ava.lang.RuntimeException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting: > //127.0.0.1:9990. The connection failed > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.undeploy(ServerDe > ploymentHelper.java:109) > at org.jboss.as.arquillian.container.ArchiveDeployer.undeploy(ArchiveDeployer.java:55) > at org.jboss.as.arquillian.container.CommonDeployableContainer.undeploy(CommonDeployableConta > iner.java:152) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$4.call(Cont > ainerDeployController.java:205) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$4.call(Cont > ainerDeployController.java:185) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOper > ation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.undeploy(Co > ntainerDeployController.java:184) > 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:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploym > entContext(ContainerDeploymentContextHandler.java:78) -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2144) blacktie wildfly subsystem build failed with can not find "threads.xml"

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2144?page=com.atlassian.jira.plugin.... ] Amos Feng commented on JBTM-2144: --------------------------------- http://172.17.131.2/view/Narayana+BlackTie/job/narayana/487/ > blacktie wildfly subsystem build failed with can not find "threads.xml" > ----------------------------------------------------------------------- > > Key: JBTM-2144 > URL: https://issues.jboss.org/browse/JBTM-2144 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Application Server Integration, BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.0.2 > > > {code} > [java] java.lang.IllegalStateException: Could not find '[subsystem=../../../../../../jboss-as/build/src/main/resources/configuration/subsystems/threads.xml, supplement=null]' > {code} > the threads.xml has been removed in the wildfly commit > https://github.com/wildfly/wildfly/commit/8caaf561bfc583314cbfee189d2b0f8... -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2144) blacktie wildfly subsystem build failed with can not find "threads.xml"

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2144?page=com.atlassian.jira.plugin.... ] Amos Feng commented on JBTM-2144: --------------------------------- http://172.17.131.2/view/Narayana+BlackTie/job/narayana-codeCoverage/113 http://172.17.131.2/view/Narayana+BlackTie/job/narayana/484/ http://172.17.131.2/view/Narayana+BlackTie/job/narayana/485/ http://172.17.131.2/view/Narayana+BlackTie/job/narayana/486/ http://172.17.131.2/view/Narayana+BlackTie/job/narayana-dualstack/169/ http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/70/ http://172.17.131.2/view/Narayana+BlackTie/job/narayana-quickstarts/53/ http://172.17.131.2/view/Narayana+BlackTie/job/narayana-windows2008-tacon... http://172.17.131.2/view/Narayana+BlackTie/job/narayana-windows2008-tacon... http://172.17.131.2/view/Narayana+BlackTie/job/narayana-windows2008-tacon... > blacktie wildfly subsystem build failed with can not find "threads.xml" > ----------------------------------------------------------------------- > > Key: JBTM-2144 > URL: https://issues.jboss.org/browse/JBTM-2144 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Application Server Integration, BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.2 > > > {code} > [java] java.lang.IllegalStateException: Could not find '[subsystem=../../../../../../jboss-as/build/src/main/resources/configuration/subsystems/threads.xml, supplement=null]' > {code} > the threads.xml has been removed in the wildfly commit > https://github.com/wildfly/wildfly/commit/8caaf561bfc583314cbfee189d2b0f8... -- 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

10 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues April 2014