October 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1957) XTS crash recovery tests fail on IBM JDK

by Ondřej Chaloupka (JIRA)

Ondřej Chaloupka created JBTM-1957: -------------------------------------- Summary: XTS crash recovery tests fail on IBM JDK Key: JBTM-1957 URL: https://issues.jboss.org/browse/JBTM-1957 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Testing Affects Versions: 4.17.10 Reporter: Ondřej Chaloupka Assignee: Ondřej Chaloupka The XTS crash recovery tests fail on IBM JDK. This seem to be a problem of Arquillian settings. What I do: - switch to IBM JDK (JAVA_HOME + PATH) - export JBOSS_HOME=/home/ochaloup/jboss/jboss-eap-* - cd XTS/localjunit/crash-recovery-tests - mvn test -Pxts.integration.tests.profile -Parq -Dtest=com.arjuna.qa.junit.TestATCrashDuringOnePhaseCommit What I get - tests fail with error: The server is already running! Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server. Please stop server before running or change to another type of container. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1938) Caching of datasource for JDBC store incompatible with WildFly :reload operation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-1938?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-1938: ----------------------------------------------- tom.jenkinson(a)redhat.com changed the Status of [bug 1009931|https://bugzilla.redhat.com/show_bug.cgi?id=1009931] from ASSIGNED to POST > Caching of datasource for JDBC store incompatible with WildFly :reload operation > -------------------------------------------------------------------------------- > > Key: JBTM-1938 > URL: https://issues.jboss.org/browse/JBTM-1938 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.11, 5.0.0.M5 > > > The JDBC object store makes a performance optimization to cache the datasource it obtains connections from. Unfortunately this is not compatible with WildFly :reload (see linked bugzilla for stack trace). > Without further performance constraints I have moved to obtaining a reference each time. If there are performance issues we might need to provide a way for the subsystem to invalidate the cached reference when :reload is called. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1943) Allow the safety interval for RecoveryXids to be configurable

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-1943?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-1943: ----------------------------------------------- tom.jenkinson(a)redhat.com changed the Status of [bug 1009981|https://bugzilla.redhat.com/show_bug.cgi?id=1009981] from NEW to POST > Allow the safety interval for RecoveryXids to be configurable > ------------------------------------------------------------- > > Key: JBTM-1943 > URL: https://issues.jboss.org/browse/JBTM-1943 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.11, 5.0.0.M5 > > > Currently it is hard coded to 10 seconds. It is possible that under load this could be possible to breach. Allow the setting to be configurable. > Breaching the threshold does not pose data integrity issues as the scenario where it becomes an issue is when the transaction has completed during a recovery scan. It will result in calling rollback(xid1) on the RM but as that RM is guaranteed to have had commit(xid1) (or rollback) on it already during transaction completion the only impact is an unsightly stack trace. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1935) Replace printStackTrace logging with the i18n logger in XARecoveryModule

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-1935?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-1935: ----------------------------------------------- tom.jenkinson(a)redhat.com made a comment on [bug 1009892|https://bugzilla.redhat.com/show_bug.cgi?id=1009892] https://github.com/jbossas/jboss-eap/pull/478 > Replace printStackTrace logging with the i18n logger in XARecoveryModule > ------------------------------------------------------------------------ > > Key: JBTM-1935 > URL: https://issues.jboss.org/browse/JBTM-1935 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Recovery > Affects Versions: 4.17.7, 4.17.10 > Reporter: Masafumi Miura > Assignee: Tom Jenkinson > Fix For: 4.17.11, 5.0.0.M5 > > > The following stderr loging is shown when XAException happened at rollback: > {code} > ERROR [stderr] (Periodic Recovery) javax.transaction.xa.XAException > ERROR [stderr] (Periodic Recovery) at org.hornetq.core.client.impl.ClientSessionImpl.rollback(ClientSessionImpl.java:1666) > ERROR [stderr] (Periodic Recovery) at org.hornetq.core.client.impl.DelegatingSession.rollback(DelegatingSession.java:494) > ERROR [stderr] (Periodic Recovery) at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.rollback(HornetQXAResourceWrapper.java:126) > ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.handleOrphan(XARecoveryModule.java:741) > ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:647) > ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:419) > ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:194) > ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) > ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) > {code} > This is thrown inside XARecoveryModule#handleOrphan(): > {code:title=ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/XARecoveryModule.java|borderStyle=solid} > private boolean handleOrphan(XAResource xares, Xid xid) > { > ...(snip)... > try > { > if(votingOutcome == XAResourceOrphanFilter.Vote.ROLLBACK) > { > jtaLogger.i18NLogger.info_recovery_rollingback(XAHelper.xidToString(xid)); > xares.rollback(xid); > } > } > catch (XAException e1) > { > e1.printStackTrace(); > ...(snip)... > {code} > I think {{e1.printStackTrace();}} should be should be replaced by using the i18n logger. For example: > {code} > jtaLogger.i18NLogger.warn_recovery_xarecovery1(_logName+".xaRecovery", XAHelper.printXAErrorCode(e1), e1); > {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, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1935) Replace printStackTrace logging with the i18n logger in XARecoveryModule

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-1935?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-1935: ----------------------------------------------- tom.jenkinson(a)redhat.com changed the Status of [bug 1009892|https://bugzilla.redhat.com/show_bug.cgi?id=1009892] from NEW to POST > Replace printStackTrace logging with the i18n logger in XARecoveryModule > ------------------------------------------------------------------------ > > Key: JBTM-1935 > URL: https://issues.jboss.org/browse/JBTM-1935 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Recovery > Affects Versions: 4.17.7, 4.17.10 > Reporter: Masafumi Miura > Assignee: Tom Jenkinson > Fix For: 4.17.11, 5.0.0.M5 > > > The following stderr loging is shown when XAException happened at rollback: > {code} > ERROR [stderr] (Periodic Recovery) javax.transaction.xa.XAException > ERROR [stderr] (Periodic Recovery) at org.hornetq.core.client.impl.ClientSessionImpl.rollback(ClientSessionImpl.java:1666) > ERROR [stderr] (Periodic Recovery) at org.hornetq.core.client.impl.DelegatingSession.rollback(DelegatingSession.java:494) > ERROR [stderr] (Periodic Recovery) at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.rollback(HornetQXAResourceWrapper.java:126) > ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.handleOrphan(XARecoveryModule.java:741) > ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:647) > ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:419) > ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:194) > ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) > ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) > {code} > This is thrown inside XARecoveryModule#handleOrphan(): > {code:title=ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/XARecoveryModule.java|borderStyle=solid} > private boolean handleOrphan(XAResource xares, Xid xid) > { > ...(snip)... > try > { > if(votingOutcome == XAResourceOrphanFilter.Vote.ROLLBACK) > { > jtaLogger.i18NLogger.info_recovery_rollingback(XAHelper.xidToString(xid)); > xares.rollback(xid); > } > } > catch (XAException e1) > { > e1.printStackTrace(); > ...(snip)... > {code} > I think {{e1.printStackTrace();}} should be should be replaced by using the i18n logger. For example: > {code} > jtaLogger.i18NLogger.warn_recovery_xarecovery1(_logName+".xaRecovery", XAHelper.printXAErrorCode(e1), e1); > {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, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1943) Allow the safety interval for RecoveryXids to be configurable

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-1943?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-1943: ----------------------------------------------- tom.jenkinson(a)redhat.com made a comment on [bug 1009981|https://bugzilla.redhat.com/show_bug.cgi?id=1009981] https://github.com/jbossas/jboss-eap/pull/478 > Allow the safety interval for RecoveryXids to be configurable > ------------------------------------------------------------- > > Key: JBTM-1943 > URL: https://issues.jboss.org/browse/JBTM-1943 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.11, 5.0.0.M5 > > > Currently it is hard coded to 10 seconds. It is possible that under load this could be possible to breach. Allow the setting to be configurable. > Breaching the threshold does not pose data integrity issues as the scenario where it becomes an issue is when the transaction has completed during a recovery scan. It will result in calling rollback(xid1) on the RM but as that RM is guaranteed to have had commit(xid1) (or rollback) on it already during transaction completion the only impact is an unsightly stack trace. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1938) Caching of datasource for JDBC store incompatible with WildFly :reload operation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-1938?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-1938: ----------------------------------------------- tom.jenkinson(a)redhat.com made a comment on [bug 1009931|https://bugzilla.redhat.com/show_bug.cgi?id=1009931] https://github.com/jbossas/jboss-eap/pull/478 > Caching of datasource for JDBC store incompatible with WildFly :reload operation > -------------------------------------------------------------------------------- > > Key: JBTM-1938 > URL: https://issues.jboss.org/browse/JBTM-1938 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.11, 5.0.0.M5 > > > The JDBC object store makes a performance optimization to cache the datasource it obtains connections from. Unfortunately this is not compatible with WildFly :reload (see linked bugzilla for stack trace). > Without further performance constraints I have moved to obtaining a reference each time. If there are performance issues we might need to provide a way for the subsystem to invalidate the cached reference when :reload is called. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1941) When an orb is recreated the JacOrbRCServiceInit class uses a cached poa rather than a new poa linked to the new orb reference

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-1941?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-1941: ----------------------------------------------- tom.jenkinson(a)redhat.com changed the Status of [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379] from NEW to POST > When an orb is recreated the JacOrbRCServiceInit class uses a cached poa rather than a new poa linked to the new orb reference > ------------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-1941 > URL: https://issues.jboss.org/browse/JBTM-1941 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTS > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.11, 5.0.0.M5 > > > See the upstream BZ for more details. Effectively you can't start/stop/start the JacOrbRCServiceInit within WildFly. > There are a couple of tweaks needed to achieve this. I will link a pull request but I will add some comments and delete this comment when I have the pull request finalized. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1941) When an orb is recreated the JacOrbRCServiceInit class uses a cached poa rather than a new poa linked to the new orb reference

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-1941?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-1941: ----------------------------------------------- tom.jenkinson(a)redhat.com made a comment on [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379] https://github.com/jbossas/jboss-eap/pull/478 > When an orb is recreated the JacOrbRCServiceInit class uses a cached poa rather than a new poa linked to the new orb reference > ------------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-1941 > URL: https://issues.jboss.org/browse/JBTM-1941 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTS > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.11, 5.0.0.M5 > > > See the upstream BZ for more details. Effectively you can't start/stop/start the JacOrbRCServiceInit within WildFly. > There are a couple of tweaks needed to achieve this. I will link a pull request but I will add some comments and delete this comment when I have the pull request finalized. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1956) BlackTie admin CLI tool tests could not start container

by Gytis Trikleris (JIRA)

Gytis Trikleris created JBTM-1956: ------------------------------------- Summary: BlackTie admin CLI tool tests could not start container Key: JBTM-1956 URL: https://issues.jboss.org/browse/JBTM-1956 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: BlackTie Reporter: Gytis Trikleris Assignee: Amos Feng Fix For: 5.0.0.M5 http://172.17.131.2/view/Narayana+BlackTie/job/narayana-windows2008-tacon... http://172.17.131.2/view/Narayana+BlackTie/job/narayana-windows2008-tacon... {code} junit.framework.AssertionFailedError: Could not start the server at junit.framework.Assert.fail(Assert.java:50) at org.jboss.narayana.blacktie.btadmin.UnadvertiseTest.setUp(UnadvertiseTest.java:39) at junit.framework.TestCase.runBare(TestCase.java:132) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:243) at junit.framework.TestSuite.run(TestSuite.java:238) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) 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:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) Running org.jboss.narayana.blacktie.btadmin.VersionTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec 20:01:58,194 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///172.17.131.21:54840) Caught an exception: Connection reset: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:189) [rt.jar:1.7.0_03] at java.net.SocketInputStream.read(SocketInputStream.java:121) [rt.jar:1.7.0_03] at java.net.SocketInputStream.read(SocketInputStream.java:203) [rt.jar:1.7.0_03] at java.io.DataInputStream.readByte(DataInputStream.java:265) [rt.jar:1.7.0_03] at org.codehaus.stomp.StompMarshaller.readLine(StompMarshaller.java:183) [wildfly-blacktie-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] at org.codehaus.stomp.StompMarshaller.unmarshal(StompMarshaller.java:94) [wildfly-blacktie-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:98) [wildfly-blacktie-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_03] {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, 6 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 October 2013