Announcement Announcement Module
No announcement yet.
JobParameters Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • JobParameters

    I do not understand the point about job parameters and their link to the restartability.

    Since M5 and as I understand, a job cannot be started if it was already run successfully with the same parameters, regardless of its restartable property.

    I have defined parameters as external information that might change over time, like a file name, queue name, etc, although they usually do not. Based on this, our jobs are developed so that they can run for example once a month: they pick up the actual date and deduce the time period to handle. Following this, the job parameters are minimal and do not vary much over time (more precisely, the environment around the job (sysdate, input files contents, etc) changes each time I run the job, but its parameters don't).

    Before M5, I could run the same job many times by setting the restartable flag to false, regardless of the status of previously run jobs. Now (1.0), I do not know how to run my jobs anymore : restartable=false throws JobRestartException, and restartable=true with previously completed jobs throws JobInstanceAlreadyCompletedException.

    The only solution I see is to add an extra job parameter each time a job is run, which role is to ensure job instances uniqueness (timesamp).
    1. Is there a cleaner way to do this ? (I do not like using an object [JobParameters] for another purpose [ensure uniqueness] than the intended one)
    2. What are the motivations behind this restartability rule ?
    3. Is my usage or understanding of job parameters wrong ?

  • #2
    Your understanding is correct - JobParameters serve as identifier, in fact they used to be JobIdentifier earlier in the milestone releases. Using an extra "identifying" job parameter is the standard way to go.

    Concerning the reasoning behind it, this is what JobInstance's javadoc says:

    Batch domain object representing a uniquely identifiable job run - it's identity is given by the pair {@link Job} and {@link JobParameters}. JobInstance can be restarted multiple times in case of execution failure and it's lifecycle ends with first successful execution.

    Trying to execute an existing JobIntance that has already completed successfully will result in error. Error will be raised also for an attempt to restart a failed JobInstance if the Job is not restartable.


    • #3
      Thanks for the reply.

      Using an extra "identifying" job parameter is the standard way to go.
      The problem with this solution is that it prevents me from restarting a failed job: each new job runs in its own job instance, and cannot be started from where the previously failed one left off (it cannot read previous job's execution context).


      • #4
        I wouldn't say the JobInstance semantics "prevent you from restarting a failed job" - it just forces you to distinguish between start and restart, which should generally be a good thing. In any case, if you want to restart something you must be able to say what needs to be restarted - there must be some notion of identity.

        I can see the JobInstance uniqueness complicates things a bit for non-restartable job, but adding timestamp parameter is easy enough - small price to pay for consistency I think (restartable and non-restartable jobs are launched the same way).


        • #5
          I would like to post another question regarding JobParameters: is there a way to prevent a job from launching when a required parameter is missing or incorrectly formatted?


          • #6
            It is not something you get out-of-box, but JobParameters validation is doable.

            I'm not sure what exactly you mean by "incorrectly formatted" but I suppose it could be handled in custom JobParametersConverter (just found we're currently missing a setter for it in CommandLineJobRunner

            I would check for missing parameters in the job launcher - e.g. by subclassing the SimpleJobLauncher or using an aspect.
            Last edited by robert.kasanicky; May 16th, 2008, 03:08 AM. Reason: added link to jira issue


            • #7
              My idea of incorrectly formated could be anything: validating that a numer is within a certain range, making sure a String adheres to a regular expression...

              Our intention is to check all parameters needed for a job are present and usable. If they aren't then the job shouldn't be launched and a message should be displayed somewhere.

              I like the idea of the jobLauncher making these checks. We'll think a bit how to use that.