Bugzilla – Full Text Bug Listing
|Summary:||Split Collector and analyzer should not be allowed|
|Severity:||normal||CC:||cvignola, issues, ScottKurz|
Description mminella 2012-11-09 19:58:58 UTC
A split is a set of steps or flows that are independent of each other running in different threads. Because they are intended to be independent, there is no need for a collector/analyzer for this functionality. Providing this allows the developer to build too much coupling between their steps.
Comment 1 ScottKurz 2012-11-09 20:35:14 UTC
I was going to comment saying I thought this change was meant to address the issue raised as Bug 4183: http://java.net/bugzilla/show_bug.cgi?id=4183 But then I read Chris' response there and it seems to suggest that if you want to "analyze" the split results on the main thread, you should transition from the split to a decider which will have the split's FlowContext(s). Will wait to hear your response then Chris.
Comment 2 cvignola 2012-11-19 11:22:08 UTC
We need a way for a decision following a split to know what happened in the split. There are two needs: 1) The decision element requires an input user exit value - which user exit value from the flow should be used? Each flow in the split produces a user exit value. 2) The decision element should have access to the user exit status from each flow in the split in case the decision depends on the unique outcome of each flow. There are a few ways I can think of to solve this: 1) the collector/analyzer model - which does invite coupling 2) a SplitListener that gets called at the end of each flow in the split and is passed the flow's exit status and whose job it is to set the final exit status for the split. 2) provide a map of flow names/exit status pairs in the split context and expose that to the decision - although since decision requires a user exit as input, one of the user exit values from the split flows would have to be selected - as a rule we could state the last flow to end determines the split's exit status. But that's non-deterministic. So what would you recommend? I think I like option 2 the best. For reference, what does Spring Batch do?
Comment 3 mminella 2012-11-19 14:47:43 UTC
For the record, Spring Batch does not view splits or flows at the same level as steps. They are constructs that are used to group steps but do not have the same metadata as a step. Because of this, a split or flow does not have a status, only the steps within it do. Since a job is ultimately constructed of steps, an overall status of a split or flow ends up being redundant.
Comment 4 cvignola 2012-11-19 15:51:09 UTC
In Spring Batch, a decider receives a StepExecution as input. When the decision follows a split what StepExecution does the decider receive? (In reply to comment #3) > For the record, Spring Batch does not view splits or flows at the same level as > steps. They are constructs that are used to group steps but do not have the > same metadata as a step. Because of this, a split or flow does not have a > status, only the steps within it do. Since a job is ultimately constructed of > steps, an overall status of a split or flow ends up being redundant.
Comment 5 mminella 2012-11-19 16:22:49 UTC
The decider receives null as the StepExecution if it follows a Split. It does also receive the JobExecution which we can get all previous StepExecutions from if needed.
Comment 6 cvignola 2012-11-29 20:01:00 UTC
We can drop the split collector/analyer. I agree it is added complexity with little gain. The spec does not expose JobExecution/StepExecution interfaces except through JobOperator. The decider has access to the SplitContext, which could carry the results of the individual flows - e.g. a map (Flow Id, Flow Exit Status) would probably suffice.