[JBoss JIRA] (JBTM-1149) Add some qa tests for the none-socket recovery manager
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1149?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-1149.
-------------------------------
> Add some qa tests for the none-socket recovery manager
> ------------------------------------------------------
>
> Key: JBTM-1149
> URL: https://issues.jboss.org/browse/JBTM-1149
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Testing
> Reporter: Tom Jenkinson
> Assignee: Ondřej Chaloupka
> Fix For: 5.0.0.M5
>
>
> By default the JBoss application server runs with a recovery manager that is not using a socket. We should try to add a crash recovery qa test that tests recovery in the different VMs but not by using the recovery manager socket API, rather waiting for periodic recovery.
> It is possible that there is a test for this, @ochaloup, in which case this issue can be closed as out of date
--
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, 8 months
[JBoss JIRA] (JBTM-1149) Add some qa tests for the none-socket recovery manager
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1149?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1149:
--------------------------------
Fix Version/s: 5.0.0.M5
(was: 5.0.0.Final)
> Add some qa tests for the none-socket recovery manager
> ------------------------------------------------------
>
> Key: JBTM-1149
> URL: https://issues.jboss.org/browse/JBTM-1149
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Testing
> Reporter: Tom Jenkinson
> Assignee: Ondřej Chaloupka
> Fix For: 5.0.0.M5
>
>
> By default the JBoss application server runs with a recovery manager that is not using a socket. We should try to add a crash recovery qa test that tests recovery in the different VMs but not by using the recovery manager socket API, rather waiting for periodic recovery.
> It is possible that there is a test for this, @ochaloup, in which case this issue can be closed as out of date
--
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, 8 months
[JBoss JIRA] (JBTM-1430) Restore commit method to AtomicAction
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1430?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1430:
--------------------------------
Fix Version/s: 5.0.0.M2
4.17.4
> Restore commit method to AtomicAction
> -------------------------------------
>
> Key: JBTM-1430
> URL: https://issues.jboss.org/browse/JBTM-1430
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.16.6
> Reporter: Mark Little
> Assignee: Tom Jenkinson
> Fix For: 4.17.4, 5.0.0.M2
>
>
> At some point someone deprecated the commit method in AtomicAction and left the following comment:
> @deprecated Only used by tests
> This is wrong. Just because we don't use the commit method in the code does not mean it is invalid in the scope of the public API. The commit method without the boolean parameter is a helper method to simplify calling the other commit with true all of the time. This was added years ago based on feedback from the OTS Current implementation, which had (in C++) a default boolean=true parameter in its signature.
--
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, 8 months
[JBoss JIRA] (JBTM-1430) Restore commit method to AtomicAction
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1430?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-1430.
-------------------------------
> Restore commit method to AtomicAction
> -------------------------------------
>
> Key: JBTM-1430
> URL: https://issues.jboss.org/browse/JBTM-1430
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.16.6
> Reporter: Mark Little
> Assignee: Tom Jenkinson
> Fix For: 4.17.4, 5.0.0.M2
>
>
> At some point someone deprecated the commit method in AtomicAction and left the following comment:
> @deprecated Only used by tests
> This is wrong. Just because we don't use the commit method in the code does not mean it is invalid in the scope of the public API. The commit method without the boolean parameter is a helper method to simplify calling the other commit with true all of the time. This was added years ago based on feedback from the OTS Current implementation, which had (in C++) a default boolean=true parameter in its signature.
--
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, 8 months
[JBoss JIRA] (JBTM-1509) Can't find resource for bundle java.util.PropertyResourceBundle, key com.arjuna.ats.internal.jta.transaction.arjunacore.timeouterror:
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1509?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-1509.
-------------------------------
> Can't find resource for bundle java.util.PropertyResourceBundle, key com.arjuna.ats.internal.jta.transaction.arjunacore.timeouterror:
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1509
> URL: https://issues.jboss.org/browse/JBTM-1509
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.6.1.CP12
> Environment: JBoss EAP 5.1.2
> Reporter: Tom Ross
> Assignee: Tom Jenkinson
> Fix For: 4.6.1.CP14
>
>
> JBoss TM prints a warning
> 17/01/13 09:18:48.672 WARN com.arjuna.ats.jta.logging.loggerI18N 5952 Thread-63 (Horn a9f5517:e5ec:50f6e612:14491 Can't find resource for bundle java.util.PropertyResourceBundle, key com.arjuna.ats.internal.jta.transaction.arjunacore.timeouterror: [key='com.arjuna.ats.internal.jta.transaction.arjunacore.timeouterror']TransactionImple.enlistResource, XAException.XAER_RMERR, < 131075, 41, 27, 80798279834849954953484848459757102535349555810153101995853481025410154495058495252574997571025353495558101531019958534810254101544950584952529850 >
> due to corrupted resource string
--
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, 8 months
[JBoss JIRA] (JBTM-1520) XMLFilePlugin fails to read the configuration if its path contains unicode characters
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1520?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-1520.
-------------------------------
> XMLFilePlugin fails to read the configuration if its path contains unicode characters
> -------------------------------------------------------------------------------------
>
> Key: JBTM-1520
> URL: https://issues.jboss.org/browse/JBTM-1520
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Common
> Affects Versions: 4.6.1.CP13
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
> Fix For: 4.6.1.CP14
>
>
> If the path to arjuna configuration file contains unicode characters the XMLFilePlugin class fails to read it. XMLFilePlugin then calls DocumentBuilder#parse(String uri) which expects the argument being a valid URI. As long as URI spec does not support unicode chars the filename in XMLFilePlugin needs to be converted to a valid URI without any unicode/special characters.
> Note that FileLocator.locateFile performs some conversions over the filename, but these do not seem to be enough.
> This bug prevents Arjuna from starting which subsequently prevents EAP from starting.
--
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, 8 months
[JBoss JIRA] (JBTM-1237) qa timeout MFACTOR (was: crashrecovery07 tests failing on Solaris11 x86/x86_64 platform)
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1237?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-1237.
-------------------------------
> qa timeout MFACTOR (was: crashrecovery07 tests failing on Solaris11 x86/x86_64 platform)
> ----------------------------------------------------------------------------------------
>
> Key: JBTM-1237
> URL: https://issues.jboss.org/browse/JBTM-1237
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing
> Affects Versions: 4.6.1.CP13
> Reporter: Ivo Studensky
> Assignee: Ondřej Chaloupka
> Fix For: 4.6.1.CP14
>
>
> When running QA testsuite on Solaris 11 x86/x86_64 platform with Oracle JDK7 I hit intermittent failures at crashrecovery07 tests.
> Affected tests:
> CrashRecovery07_Test04
> CrashRecovery07_Test05
> CrashRecovery07_Test11
> CrashRecovery07_Test12
> output of Test05 (qa/results/113/task_0_out):
> {noformat}
> Sleeping for 180000ms.
> Test will fail because we have just received value 2 for resource 0
> Test will fail because we have just received value 2 for resource 1
> Test has failed because we got 2 for 2
> Failed
> {noformat}
> output of Test11 (qa/results/25/task_0_out):
> {noformat}
> Sleeping for 360000ms.
> Test will fail because we have just received value 2 for resource 0
> Test will fail because we have just received value 2 for resource 1
> Test will fail because we have just received value 2 for resource 2
> Test has failed because we got 2 for 3
> Failed
> {noformat}
> Complete logs for the two issues detailed above can be found here:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBoss%20TS/view/JBo...
> output of Test04 (qa/results/92/task_0_out):
> {noformat}
> Sleeping for 450000ms.
> Test will fail because we have just received value 2 for resource 0
> Test has failed because we got 2 for 1
> Failed
> {noformat}
> output of Test12 (qa/results/14/task_0_out):
> {noformat}
> Sleeping for 450000ms.
> Test will fail because we have just received value 2 for resource 0
> Test will fail because we have just received value 2 for resource 1
> Test will fail because we have just received value 2 for resource 2
> Test has failed because we got 2 for 3
> Failed
> {noformat}
> Complete logs for Test04 and Test12 can be found here:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBoss%20TS/view/JBo...
--
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, 8 months