Bug 4557 - Is SplitContext necessary?
Is SplitContext necessary?
Status: RESOLVED FIXED
Product: jbatch
Classification: Unclassified
Component: source
1
All All
: P5 normal
: ---
Assigned To: cvignola
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-18 15:19 UTC by mminella
Modified: 2013-02-27 21:14 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mminella 2013-01-18 15:19:58 UTC
Section 7.8.5 on page 94 defines a SplitContext.  I don't see the explicit need for this context or the need to be able to get distinct flow results since both constructs are nothing more than grouping options for steps.  I would expect the only thing of importance here to be the step statuses themselves.
Comment 1 cvignola 2013-01-23 20:21:11 UTC
The main purpose of the split context is to expose a list of statuses from the flows comprising the split so a decider can make a decision based on the outcome of one or more flows.
Comment 2 mminella 2013-01-24 15:02:49 UTC
I'm looking at the Decider interface and it seems that since it only accepts a single BatchContext (SB explicitly receives a JobExecution and a StepExecution), that component becomes less reusable than it could be (since the implementation will need to know what type of context it is receiving and cast accordingly).  

That being said, wrapping the flow statuses in a single package makes sense.
Comment 3 cvignola 2013-01-24 20:08:30 UTC
(In reply to comment #2)

I'm curious:  

1) What does the StepExecution contain when the Decider follows a Flow?

2) What does the StepExecution contain when the Decider follows a Split?


> I'm looking at the Decider interface and it seems that since it only accepts a
> single BatchContext (SB explicitly receives a JobExecution and a
> StepExecution), that component becomes less reusable than it could be (since
> the implementation will need to know what type of context it is receiving and
> cast accordingly).  
> That being said, wrapping the flow statuses in a single package makes sense.
Comment 4 cvignola 2013-02-05 01:38:18 UTC
SplitContext will be removed.  However,  decider still needs a way to know what happened to the flows in a split.  So the proposal is:

1) Decider artifact supports two signatures:

String decide(StepStatus)
String decide(StepStatus[])


2) StepStatus includes two values;  step id and step exit status


3) Decider is invoked as follows:

a) if preceded by a step, with the StepStatus of that step;
b) if preceded by a flow, with the StepStatus of the last step that executed as part of that flow;
c) if preceded by a split, with an array of StepStatus, one StepStatus for the last step that executed as part of each flow in the split.
Comment 5 mminella 2013-02-05 22:25:46 UTC
Adding an id to the StepStatus doesn't make sense to me.  Then it isn't a status anymore.  Why not just pass the StepExecutions to the Decider (they contain both the BatchStatus and ExitStatus so all information needed would be available)?
Comment 6 ScottKurz 2013-02-07 15:00:57 UTC
BTW.. we still don't have spec text mandating that deciders rerun on restart.   I'd suggested it be mentioned as part of a more general discussion of restart (I could look up the bug).    I think that last discussion, btw, got lost in the details of pathological property substitution.
Comment 7 cvignola 2013-02-08 18:55:43 UTC
(In reply to comment #5)

You're right.  The StepStatus is just a stripped down StepExecution.  So let' define decider as:

String decide(StepExcution)
String decide(StepExecution[])

or do we prefer simply: 

String decide(StepExecution[])

And the array size is exactly 1 when decider follows a step or flow.  The array size would be > 1 if and only if decider follows a split - i.e. one StepExecution for the final step in each flow. 

> Adding an id to the StepStatus doesn't make sense to me.  Then it isn't a
> status anymore.  Why not just pass the StepExecutions to the Decider (they
> contain both the BatchStatus and ExitStatus so all information needed would be
> available)?
Comment 8 cvignola 2013-02-27 21:14:20 UTC
We have settled on having only:

String decide(StepExecution[]) (to be amended in PFD v1.5)

and SplitContext was removed in an earlier PFD draft.