Announcement Announcement Module
Collapse
No announcement yet.
Pause/Resume Job Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Pause/Resume Job

    Hello,
    Is it possible to pause a job and allow other job to run and on completion of the second job, I can resume the first one mutually.

    Scenario in Details:
    I am running a job (say footballJob) with an assumption that it is consuming 95% CPU. Now I want other job (say simpleTaskletJob) to be executed in between within same context i.e. same JVM. Because of less availability of resources I decided to pause or suspend the first Job (footballJob) and Start second Job(simpleTaskletJob).

    Suppose my commit interval is 100 and I am at 74th record.
    1) Can I pause the job and save the records.
    2) Can I run second job in same context or JVM.
    3) Can I resume first job from 75th record with same context or same JVM.

    I am more interested in the pausing i.e. suspending of job and then resuming from the last processed record.

  • #2
    It doesn't make sense to pause in any way that consumes resources (eg with Thread.sleep) so this requirement has to be met by stopping and restarting the job. Actually, that reminds me, we need to add a method to the JobLauncher interface to allow you to stop an individual job (as opposed to all of them). Add a JIRA if you want to track the progress.

    Comment


    • #3
      Hello Dave,
      1) I have already exposed stop method (i.e. stop(String jobName)) in the Job Launcher.Truely speaking,I am not sure that calling the stop method performs graceful shutdown. By graceful shutdown, I mean same as point 1 mentioned above i.e. saving 74 records.

      2)How can I restart the job AGAIN from 75th record ?

      Comment


      • #4
        1) I would define graceful shutdown as waiting for the present chunk to finish, and that not continuing on. Which is what the framework should be doing today by marking the two RepeatTemplates as complete. This means that it would finish processing the 100 records (75 - 100) and then stop the job. An ungraceful shutdown would discard the entire transaction and finish. I suppose we could finish the transaction immediately (committed what has already been finished), but the only reason to do so would be if the it would take longer than a second or two to finish the current transaction (in the vast majority of cases it should only take milliseconds) Considering some of the changes for chunk processing in m4, I think there could be complications with that and would prefer to let all chunks that have started, finish, before gracefully shutting down.

        2) You can only restart a job from the last place it committed, if this was the 75th record, then it will start from there, otherwise, it will be the last committed record.

        Comment


        • #5
          1) How can I perform graceful shutdown?
          Is calling stop(String JobName) is equivalent to perform graceful shutdown or there is another to do so.

          2) Can any one explain how the restart will work.
          i.e. I have run first job and terminated in between then started second job in same context or JVM. On completion of second job i will restart the first again.

          Now my question is that: Does the batch environment checks in the BATCH_JOB table in the JOB_NAME column for the job with the same name exists and corresponding value in STATUS.
          If the value in the STATUS for corresponding job is 'FAILED' or 'STOPPPED' then it will start the job from the last committed point.

          Comment


          • #6
            Before answering, I want to point out that we're currently working on modifying job launching and how jobs are identified for Milestone 4. However, I will give the answer based on M3.

            1) How can I perform graceful shutdown?
            Is calling stop(String JobName) is equivalent to perform graceful shutdown or there is another to do so.
            Using the stop method no the JobLauncher interface will perform a graceful shutdown. (Note, this will likely change to stop(JobIdentifier) in M4)

            2) Can any one explain how the restart will work.
            i.e. I have run first job and terminated in between then started second job in same context or JVM. On completion of second job i will restart the first again.
            Everytime there is a commit of the 'business' transaction, the transaction you as a developer are using to process items, we store 'restart data'. To use files as an example, it would store the last line number read in. If you restart the job with the same JobIdentifier (which means you're running the same JobInstance again) we will use the persisted restart data to restart your job from the same line number.

            Comment


            • #7
              Sorry, I didn't notice the last question:

              Now my question is that: Does the batch environment checks in the BATCH_JOB table in the JOB_NAME column for the job with the same name exists and corresponding value in STATUS.
              If the value in the STATUS for corresponding job is 'FAILED' or 'STOPPPED' then it will start the job from the last committed point.
              In M3, the status is not checked for determining restart. It does however, check that the job name, schedule date, and job key are the same, and if so considers it the same 'instance', and if that instance has stored restart data, it will attempt to pass it on.

              Comment


              • #8
                Where exactly the information or the values for the restart data is stored.

                If I forcefully stop a job and try to run the same job on same day it will resart,wouldnt it ?
                If yes, where will it look for the restart data.

                Comment


                • #9
                  If I forcefully stop a job and try to run the same job on same day it will resart,wouldnt it ?
                  Sort of. If the job name, key and schedule date are the same, then it will consider the job instance you're running to be the same as one you're run before, and will reconstitute it from the database, rather than creating a new one. The restart data itself will be found in this reconstituted object, specifically, the StepInstance.

                  Comment

                  Working...
                  X