-
Notifications
You must be signed in to change notification settings - Fork 76
CTS Batch Test with WildFly
-
The general guide for running tck7 (cts7) with WildFly: https://community.jboss.org/wiki/TCK7Guide
-
start WildFly in debug mode on port (e.g., 8787, the default one in standalone.conf):
cd $JBOSS_HOME/bin ./standalone.sh --debug 8787
-
attach debugger to address 8787 in IDE
-
set breakpoints in cts test classes, appserver classes, or library classes. CTS batch tests are vehicle tests, which means test code is packaged, deployed and executed in appserver. So breakpoints in test code will show up in WildFly debug sessions. Batch tests run in 2 vehicles: ejb vehicle, and web vehicle (servlet vehicle + jsp vehicle)
-
run individual test that you want to debug, e.g.,:
cd /Users/cfang/dev/jboss-tck/tck7/trunk/src/com/ibm/jbatch/tck/tests/jslxml ant runclient -Dtest=testInvokeJobWithOnePartitionedStepExitStatus_from_web -Dtest.client=ParallelExecutionTests.java
-Dtest.client sysprop tells cts harness in which test class to find the test method. The default value is Client.java. Since this test directory uses non-default test class names, so you need to specify -Dtest.client sysprop.
- optionally, to undeploy any test apps that may be left deployed on WildFly server after terminating the test run with Ctrl-C:
(in current test directory) ant undeploy
- optionally, use jberet tck-porting-impl in lieu of the RI tck porting impl packaged inside test jar, war and ear files, for better error messages and performance. You will need to add jberet tck-porting-impl classes to test archives, and also overwrite META-INF/services/com.ibm.jbatch.tck.spi.JobExecutionWaiterFactory.
mkdir -p $HOME/tmp/batch-tck-spi-impl-classes/WEB-INF/classes cd $HOME/tmp/batch-tck-spi-impl-classes/WEB-INF/classes jar xvf $HOME/.m2/repository/org/jberet/tck-porting-impl/1.0.0.Beta1-SNAPSHOT/tck-porting-impl-1.0.0.Beta1-SNAPSHOT.jar /bin/rm -rf META-INF/MANIFEST.MF META-INF/INDEX.LIST META-INF/maven/ ## update ejb jar and ejb client jar cd $HOME/tmp/batch-tck-spi-impl-classes/WEB-INF/classes jar uvf $TS_HOME/dist/com/ibm/jbatch/tck/tests/jslxml/jslxml_ejb_vehicle_client.jar META-INF org jar uvf $TS_HOME/dist/com/ibm/jbatch/tck/tests/jslxml/jslxml_ejb_vehicle_ejb.jar META-INF org ## update war file cd $HOME/tmp/batch-tck-spi-impl-classes/ jar uvf $TS_HOME/dist/com/ibm/jbatch/tck/tests/jslxml/jslxml_web_vehicle_web.war WEB-INF ## update ear files cd $TS_HOME/dist/com/ibm/jbatch/tck/tests/jslxml/ jar uvf jslxml_ejb_vehicle.ear jslxml_ejb_vehicle_ejb.jar jslxml_ejb_vehicle_client.jar jar uvf jslxml_web_vehicle.ear jslxml_web_vehicle_web.war
While running certain jslxml/ tests (ParallelExecutionTests.java) in ejb vehicle, I see transaction-related failures:
java.lang.IllegalStateException: BaseTransaction.checkTransactionState - ARJUNA016051: thread is already associated with a transaction! [com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.checkTransactionState(BaseTransaction.java:266), com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:68), com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.begin(BaseTransactionManagerDelegate.java:65), org.jboss.tm.usertx.client.ServerVMClientUserTransaction.begin(ServerVMClientUserTransaction.java:147), org.jberet.runtime.runner.StepExecutionRunner.beginPartition(StepExecutionRunner.java:287), org.jberet.runtime.runner.StepExecutionRunner.runBatchletOrChunk(StepExecutionRunner.java:189), org.jberet.runtime.runner.StepExecutionRunner.run(StepExecutionRunner.java:134), org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:161), org.jberet.runtime.runner.CompositeExecutionRunner.runFromHeadOrRestartPoint(CompositeExecutionRunner.java:87), org.jberet.runtime.runner.JobExecutionRunner.run(JobExecutionRunner.java:58), java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471), java.util.concurrent.FutureTask.run(FutureTask.java:262), java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145), java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615), java.lang.Thread.run(Thread.java:724),org.jboss.threads.JBossThread.run(JBossThread.java:122)]
This could be caused by the EJB CMT being propagated to batch threads. Need to check if we need to isolate batch threads from any existing transacton context. This issue may be more evident in ee/ test directory, which specifically test transactions.