[JBoss JIRA] Created: (JBTM-871) Simple WS-BA quickstart
by Paul Robinson (JIRA)
Simple WS-BA quickstart
-----------------------
Key: JBTM-871
URL: https://issues.jboss.org/browse/JBTM-871
Project: JBoss Transaction Manager
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
The booking application is a good example of how to use XTS, but has a steep learning curve for those new to XTS. This task is to create the simplest possible example using WS-BA. It is intended as a first port-of-call when learning WS-BA.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (JBTM-863) Move hudson based XTS tests into AS7 integration test suite
by Andrew Dinn (JIRA)
Move hudson based XTS tests into AS7 integration test suite
-----------------------------------------------------------
Key: JBTM-863
URL: https://issues.jboss.org/browse/JBTM-863
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: XTS
Reporter: Andrew Dinn
The XTS unit and interop tests are currently run as a hudson job. Thsi is because they need to run in a container with a full WS stack available. It would be better if all or, at least, some of these tests were included in the AS7 integration test suite, most likely using Arquilian to manage deployment of the test wars to AS7.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (JBTM-817) Automate execution of XTS crash recovery tests
by Andrew Dinn (JIRA)
Automate execution of XTS crash recovery tests
----------------------------------------------
Key: JBTM-817
URL: https://jira.jboss.org/browse/JBTM-817
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public (Everyone can see)
Components: XTS
Affects Versions: 4.13.0
Reporter: Andrew Dinn
Fix For: 4.15.0
The XTS codebase includes crash recovery tests in the sar/tests subtree which currently need to be executed manually. This needs to be changed so that the current tests can be run automatically via Hudson. After this has been completed it should then be possible to extend the test suite to exercise scenarios not yet covered by the current range of tests.
The tests themselves employ a web service client and several web services which are deployed to the app server with the test code. The behaviour of the client and web services can be scripted so this single deployment is capable of exercising all the scenarios which are required in order to lead up to a crash. However, automation is not straightforward for several reasons:
Execution of the tests requires starting up an app server twice, the first time so that it can be crashed at a specific point during execution then a second time so that recovery processing can be checked. The JBossTS codebase includes some utilities which can be used to help manage startup and shutdown of the JBoss AS instance.
Crashing of the app server and tracing of execution during the first and second runs requires the use of the Byteman agent and Byteman rules. Suitable Byteman rule scripts exist for all the current tests, However, trace output is currently written to a file and the output is verified by eyeball. Timing variations mean that this output does not always have a fixed format. Also, validation requires checking that identifiers printed during the first and second run match up. It would be worth investigating an alternative way of collecting and validating this trace information e.g. using the dtest package contributed to Byteman by Jonathan Halliday. dtest has been used to test similar scenarios in the JBossTS JTA - XTS bridge code (the latter is in the txbridge source tree).
Timing variations also mean that execution of recovery code may needs to be manipulated using Byteman rules in order to ensure that the circumstances specified in the test scenario are actually met. This can involve introducing delays or dropping messages to ensure that events are handled in a specific order. The existing Bbyteman scripts include rules to achieve this where needed by the current tests. However, once again, this complicates automation of the trace validation process since it requires some of the traced operations to be discounted until an occurrence which has been engineered is identified.
In the longer run the tests will need to be extended in two dimensions.
Firstly, the current test locates the client, web services and transaction coordinator in one application server. The client, web services and transaction coordinator need to be tested when they are deployed in different app servers in various possible combinations and the correct handling of a crash by one or more of these app servers needs to be validated.
Secondly, the current tests only test normal recovery situations. It will also be necessary to simulate failures in the recovery process, either by scripting the web service behaviour or by injecting faults using Byteman rules.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (JBTM-901) Classloading exceptions during the periodic recovery process
by Ivo Studensky (JIRA)
Classloading exceptions during the periodic recovery process
------------------------------------------------------------
Key: JBTM-901
URL: https://issues.jboss.org/browse/JBTM-901
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: TxBridge
Affects Versions: 4.15.3
Reporter: Ivo Studensky
Assignee: Paul Robinson
Some classloading exceptions happen during the periodic recovery process if AS7 started with standalone-xts.xml configuration, see the log snippets bellow.
It seems like some missing deps to javax.resource.api and javax.transaction.api in xts module descriptor. But it could also be that the standalone-xts.xml configuration file in AS7 is out of date.
Could you check this pls? Note: it was tested on the latest AS7 master.
{code}
13:08:17,500 ERROR [stderr] (Periodic Recovery) Exception in thread "Periodic Recovery" java.lang.NoClassDefFoundError: javax/transaction/SystemException
13:08:17,500 ERROR [stderr] (Periodic Recovery) at org.jboss.jbossts.txbridge.outbound.OutboundBridgeRecoveryManager.periodicWorkSecondPass(OutboundBridgeRecoveryManager.java:87)
13:08:17,501 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789)
13:08:17,501 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371)
13:08:17,501 ERROR [stderr] (Periodic Recovery) Caused by: java.lang.ClassNotFoundException: javax.transaction.SystemException from [Module "org.jboss.xts:main" from local module loader @2ca6d51e (roots: /home/studensky/job/git/jboss-as/build/target/jboss-as-7.1.0.Alpha1-SNAPSHOT/modules)]
13:08:17,501 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
13:08:17,501 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:361)
13:08:17,501 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:333)
13:08:17,502 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:310)
13:08:17,502 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:103)
13:08:17,502 ERROR [stderr] (Periodic Recovery) ... 3 more
{code}
{code}
Exception in thread "Periodic Recovery" java.lang.NoClassDefFoundError: javax/resource/spi/XATerminator
13:18:56,834 ERROR [stderr] (Periodic Recovery) at org.jboss.jbossts.txbridge.inbound.InboundBridgeRecoveryManager.getIndoubtSubordinates(InboundBridgeRecoveryManager.java:227)
13:18:56,834 ERROR [stderr] (Periodic Recovery) at org.jboss.jbossts.txbridge.inbound.InboundBridgeRecoveryManager.periodicWorkSecondPass(InboundBridgeRecoveryManager.java:196)
13:18:56,834 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789)
13:18:56,835 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (JBTM-893) Build is dependent upon Sun's JDK
by Tom Jenkinson (JIRA)
Build is dependent upon Sun's JDK
---------------------------------
Key: JBTM-893
URL: https://issues.jboss.org/browse/JBTM-893
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Tom Jenkinson
Assignee: Michael Musgrove
Fix For: 5.0.0.M2
We have a dependency in the arjuna module on jconsole.jar which is not shipped in openjdk for instance so our pom refers to JAVA_HOME/lib/jconsole.jar.
This needs reviewing, we could add a profile that only includes the dependency on a build when the file exists and in other profiles does not build the classes that require this Jar, but if the code is critical we need to think about a rewrite to not depend on the (presumably) proprietary Jar.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month