Exception if transaction timeout occured before partitions complete

[fantarama]

If I run a partitioned step with a low transaction timeout (15s) all partitions run well, everyone in a separate transaction that stay alive for max 1s, but the partition analyzer loop is in a unique transaction so if timeout occured then at the end of all partition executions I got this exception:

While partition executions:

[com.arjuna.ats.arjuna](Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff0a7a1b38:-6a4100d1:53f59ba8:4e8 in state RUN
[com.arjuna.ats.arjuna](Transaction Reaper Worker 0) ARJUNA012095: Abort of action id 0:ffff0a7a1b38:-6a4100d1:53f59ba8:4e8 invoked while multiple threads active within it.
[com.arjuna.ats.arjuna](Transaction Reaper Worker 0) ARJUNA012108: CheckedAction::check - atomic action 0:ffff0a7a1b38:-6a4100d1:53f59ba8:4e8 aborting with 1 threads active!

Then at partitions end:

ERROR [org.jberet](Batch Thread - 10) JBERET000007: Failed to run job xxx, xxx, org.jberet.job.model.Step@3a6838f9: java.lang.IllegalStateException: BaseTransaction.rollback - ARJUNA016074: no transaction!
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:139) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.rollback(BaseTransactionManagerDelegate.java:114)
at org.jberet.runtime.runner.StepExecutionRunner.beginPartition(StepExecutionRunner.java:348) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
at org.jberet.runtime.runner.StepExecutionRunner.runBatchletOrChunk(StepExecutionRunner.java:202) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
at org.jberet.runtime.runner.StepExecutionRunner.run(StepExecutionRunner.java:138) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
at org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:164) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
at org.jberet.runtime.runner.CompositeExecutionRunner.runFromHeadOrRestartPoint(CompositeExecutionRunner.java:88) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
at org.jberet.runtime.runner.JobExecutionRunner.run(JobExecutionRunner.java:58) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
at org.wildfly.jberet.services.BatchEnvironmentService$WildFlyBatchEnvironment$1.run(BatchEnvironmentService.java:144) [wildfly-jberet-8.1.0.Final.jar:8.1.0.Final]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_05]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_05]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)

[fantarama]

JSR define this workflow! So my question is how can I handle long time partition execution if analyzer work in a unique transaction? I excpected that was the single method in transaction not the loop.

6 begin transaction // thread A
7 // Actions 9-12 run continuously until all partitions end.
8 // when collector payload arrives:
9 <->PartitionAnalyzer.analyzeCollectorData // thread A
10 // when partition ends:
11 <->PartitionAnalyzer.analyzeStatus // thread A
12. // Remaining actions run after all partitions end:
13. // if rollback condition occurs:
14. <->[PartitionReducer.rollbackPartitionedStep] // thread A
15.
16. // else not rollback
17. <->[PartitionReducer.beforePartitionedStepCompletion] // thread A
18. commit transaction // thread A

[chengfang]

will look into it next.

[chengfang]

According to the spec section you quoted above (section 11.7), all the work on the main thread by analyzer and reducer are in one single transaction. So I think you will need to adjust tx timeout to allow for time taken by analyzer and reducer processing, partition scheduling and dispatching and communication overhead. The scope of the partition main thread transaction (single-method vs loop), I will check with spec expert group to see why it is designed this way.
https://java.net/projects/jbatch/lists/public/archive/2014-08/message/1

[chengfang]

See RI Bug https://java.net/bugzilla/show_bug.cgi?id=6356
PartitionAnalyzer transaction boundary on partitioned chunk (and batchlet) step need clarification

[fantarama]

Yes they admit taht spec need a clarification. By now to solve my problem i've made a fix to jberet and I've updated my Wildfly 8.1 server installation.

[chengfang]

Somewhat related issue:
JBERET-117 Arjuna transaction timeout with partitioned step (there is no partition analyzer or collector)