Bug 4562 - JobParameters on restart
JobParameters on restart
Status: RESOLVED FIXED
Product: jbatch
Classification: Unclassified
Component: source
1
All All
: P5 critical
: ---
Assigned To: cvignola
: 4561 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-18 16:17 UTC by mminella
Modified: 2013-02-14 18:51 UTC (History)
3 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 16:17:11 UTC
In section 7.8.10 on page 100, the JobOperator#restart(long executionId) is defined.  Since JobParameters are at the execution level and can be changed from execution to execution, how are JobParameters handled on restart?  In the current version of SB, you can't change parameters from one execution to the next so that isn't an issue.  We are in the process of adding that feature (to be more in line with the spec).  We are currently proposing that any non-identifying parameters (all parameters from the JSR's viewpoint) would be required to be repassed in with each restart.
Comment 1 cvignola 2013-01-23 18:28:07 UTC
So what are you proposing?  That the spec reinstate restart parameters or that getJobParameters() move from JobExecution to JobInstance?
Comment 2 cvignola 2013-01-23 18:57:45 UTC
*** Bug 4561 has been marked as a duplicate of this bug. ***
Comment 3 cvignola 2013-02-01 23:44:23 UTC
We agree to add back restart parameters.  This change may not make it into the final approval ballot due to time constraints.  If we can't add it in time for the FAB,  we will add it before final release. 

The spec will say (roughly) that:

1) Job parameters may be specified on restart.

2) Whether a job parameter is required or not (on start or restart) depends on the job design.  

For example,

<property name="inputFile" 
             value=#{jobParameters['step1.inputFile']?:"input.txt";}/>

Implies job parameter "step1.inputFile" is optional because there is a default.

Whereas: 

<property name="inputFile" 
             value=#{jobParameters['step1.inputFile']}/>


Implies job parameter "step1.inputFile" is required.  Although, in fact, the substitution reference will resolve to null and that may be an acceptable value to the property consumer.

So whether a job parameter is or is not required depends on the job design and should be documented as part of the job definition.   

The runtime makes no requirement on which job parameters, if any, are passed in on start or restart.  

If a job parameter is used in a position without a default such that it is effectively required, for example:

<chunk item-count="#{jobParameters['itemCount']}" ... />

the runtime will still not require that the job parameter be passed in. If a required job parameter is not passed in, it may result in an invalid job, which will terminate in error. 

3) Whether or not jobParameters may be used in substitution on attributes that affect job flow (such as 'on' and 'to' attributes) is still be studied and may be restricted.
Comment 4 cvignola 2013-02-01 23:50:58 UTC
(In reply to comment #3)

I neglected to add item #4 to the list.

4) job parameters (from start or restart) will be stored on the JobExecution.
Comment 5 cf126330 2013-02-02 03:39:54 UTC
(In reply to comment #3)

> For example,
> 
> <property name="inputFile" 
>              value=#{jobParameters['step1.inputFile']?:"input.txt";}/>
> 

I think the value should be formated as:
              value="#{jobParameters['step1.inputFile']}?:input.txt;"/>

Note the position of }. I hope it's just a typo, and the syntax has not changed.
Comment 6 mminella 2013-02-05 19:47:29 UTC
I'd like to vote for not allowing parameters to have an impact on the flow of a job (for example, using them in the on attribute of a next tag).  It opens up a level of ambiguity that is unreasonable IMHO.
Comment 7 cvignola 2013-02-05 19:53:45 UTC
Michael, I agree completely.  I believe we have to choose between disallowing substitution altogether on attributes that govern flow vs disallowing re-substitution on those same attributes during restart.
Comment 8 mminella 2013-02-05 19:55:11 UTC
I'd vote for not allowing substitution on those attributes all together both for simplicity and consistency.
Comment 9 ScottKurz 2013-02-05 20:13:28 UTC
So Michael, good point that it's cleaner and more obvious to ban substitution completely than to only ban it on restart.  

Two counterpoints maybe; 

1) assuming a decider is going to re-execute on restart, we're still open to a different execution sequence.

2) the easiest way to restrict this, banning all substitution, also eliminates the possibility of substitution with 'jobProperties'.   Maybe this isn't as big a deal for exit status matching against @on attributes, but there could be examples (I'm thinking partition plan @partitions) where it would be useful to have a job-level property that steps can reuse... but it gets awfully complicated to say you can do one substitution but not the other.

But still, let's build the prohibited (or questionable) substitution list:

We've got @on attributes for next, end, stop, fail elements.

How about @abstract (job/step) and @restartable (job) as well... and partition plan @partitions.

Any more?
Comment 10 cvignola 2013-02-08 19:38:47 UTC
(In reply to comment #5)

value="" is the correct syntax.  What you saw is a typo.

> (In reply to comment #3)
> > For example,
> > 
> > <property name="inputFile" 
> >              value=#{jobParameters['step1.inputFile']?:"input.txt";}/>
> > 
> I think the value should be formated as:
>               value="#{jobParameters['step1.inputFile']}?:input.txt;"/>
> Note the position of }. I hope it's just a typo, and the syntax has not
> changed.
Comment 11 cvignola 2013-02-14 18:51:02 UTC
Restart parameters added back to JobOperator in PFD v1.4.  More work is required to explain what attributes can't be changed (e.g. sequence related). That update will be tracked separately.