search

jakartaee / batch

The Jakarta Batch project produces the Batch Specification and API.
https://projects.eclipse.org/projects/ee4j.batch
Apache License 2.0
13 stars 18 forks source link

PartitionAnalyzer transaction boundary on partitioned chunk (and batchlet) step need clarification #175

Closed dashorst closed 3 years ago

dashorst commented 3 years ago

At €dayjob we run into this transaction warning:

19:54:39,597 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff0a2a03d0:-3f2eaa3:5f7f5037:c26 in state  RUN
19:54:39,601 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012095: Abort of action id 0:ffff0a2a03d0:-3f2eaa3:5f7f5037:c26 invoked while multiple threads active within it.
19:54:39,605 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012381: Action id 0:ffff0a2a03d0:-3f2eaa3:5f7f5037:c26 completed with multiple threads - thread Batch Thread - 9 was in progress with java.base@11.0.8/jdk.internal.misc.Unsafe.park(Native Method)
java.base@11.0.8/java.util.concurrent.locks.LockSupport.park(Unknown Source)
java.base@11.0.8/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source)
java.base@11.0.8/java.util.concurrent.LinkedBlockingQueue.take(Unknown Source)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.StepExecutionRunner.beginPartition(StepExecutionRunner.java:364)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.StepExecutionRunner.runBatchletOrChunk(StepExecutionRunner.java:222)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.StepExecutionRunner.run(StepExecutionRunner.java:144)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:164)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.CompositeExecutionRunner.runJobElement(CompositeExecutionRunner.java:128)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.StepExecutionRunner.run(StepExecutionRunner.java:202)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:164)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.CompositeExecutionRunner.runJobElement(CompositeExecutionRunner.java:128)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.StepExecutionRunner.run(StepExecutionRunner.java:202)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:164)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.CompositeExecutionRunner.runJobElement(CompositeExecutionRunner.java:128)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.StepExecutionRunner.run(StepExecutionRunner.java:202)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:164)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.CompositeExecutionRunner.runFromHeadOrRestartPoint(CompositeExecutionRunner.java:88)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.FlowExecutionRunner.run(FlowExecutionRunner.java:48)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.CompositeExecutionRunner.runFlow(CompositeExecutionRunner.java:202)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.CompositeExecutionRunner.runFromHeadOrRestartPoint(CompositeExecutionRunner.java:95)
org.jberet.jberet-core@1.3.6.Final//org.jberet.runtime.runner.JobExecutionRunner.run(JobExecutionRunner.java:60)
org.wildfly.extension.batch.jberet@20.0.1.Final//org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentService$WildFlyBatchEnvironment$1.run(BatchEnvironmentService.java:180)
org.wildfly.extension.request-controller@12.0.3.Final//org.wildfly.extension.requestcontroller.ControlPointTask.run(ControlPointTask.java:46)
org.wildfly.extension.batch.jberet@20.0.1.Final//org.wildfly.extension.batch.jberet.thread.pool.WildFlyJobExecutor$1.run(WildFlyJobExecutor.java:72)
org.jberet.jberet-core@1.3.6.Final//org.jberet.spi.JobExecutor$1.run(JobExecutor.java:99)
java.base@11.0.8/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.base@11.0.8/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.base@11.0.8/java.lang.Thread.run(Unknown Source)
org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)

Some investigation lead me to find issue JBERET-117, which discusses the same issue we ran into (in 2014). In a comment from 2014, the committer refers to a bug in the bugzilla of the JSR 352 spec group at java.net. Since java.net is now defunct, the link doesn't point to anything useful:

The batch spec group is pondering getting rid of global transaction around partition analyzers, or something similar, in the next spec version. See spec bug PartitionAnalyzer transaction boundary on partitioned chunk (and batchlet) step need clarification These spec changes, when implemented in JBeret, will not be backward compatible with existing JBeret versions. So feel free to add your feedback to the spec bug.

Is this spec bug already solved?

scottkurz commented 3 years ago

Hi @dashorst. Thanks for bringing it up.

No, this has not been addressed in the spec. We did port over a bunch of issues from the original JSR 352 bugzilla, so I think we have this covered already by, e.g.: https://github.com/eclipse-ee4j/batch-api/issues/58 https://github.com/eclipse-ee4j/batch-api/issues/59

So we can probably close this as a duplicate.

But please do feel free to add to the discussion in one of those issues.

Thank you.