Loading...

XML

Word

Printable

Steps to Reproduce:
Hide

1. Get the sample project from https://github.com/lbtc-xxx/jsr352-split
2. Deploy
3. Access http://localhost:8080/jsr352-split/ (servlet kicks the batch)

You can see that "step2" executed before completion of "split1-flow1-step1".

23:12:18,414 INFO [stdout] (batch-batch - 2) stepName: split1-flow1-step1 start sleeping 23:17:18,400 INFO [stdout] (batch-batch - 1) stepName: step2 start sleeping 23:18:58,416 INFO [stdout] (batch-batch - 2) stepName: split1-flow1-step1 done sleeping
Show
1. Get the sample project from https://github.com/lbtc-xxx/jsr352-split 2. Deploy 3. Access http://localhost:8080/jsr352-split/ (servlet kicks the batch) You can see that "step2" executed before completion of "split1-flow1-step1". 23:12:18,414 INFO [stdout] (batch-batch - 2) stepName: split1-flow1-step1 start sleeping 23:17:18,400 INFO [stdout] (batch-batch - 1) stepName: step2 start sleeping 23:18:58,416 INFO [stdout] (batch-batch - 2) stepName: split1-flow1-step1 done sleeping

I have a long-running split element in my jobXML, and sometimes it takes 300 seconds over.

I don't want to execute following step before precedence split complete, but it will be transitioned unexpectedly after 300 seconds.

And I found the implementation of 300 seconds threshold in org.jberet.runtime.runner.SplitExecutionRunner:

private static final long SPLIT_FLOW_TIMEOUT_SECONDS = 300;
...
latch.await(SPLIT_FLOW_TIMEOUT_SECONDS, TimeUnit.SECONDS);

I can't found this behavior in the spec. or did I overlooked something?

is related to

JBERET-55 Flow/Split transitioning & termination not fully defined

JBERET-125 Split may cause deadlock