Announcement Announcement Module
No announcement yet.
JobOperator:stop() Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • JobOperator:stop()

    I have the below model.

    One (master)partitionstep, and it contains slave TaskletStep(s), within which I call my business process.
    If the business process successfully completes, I mark the envelope TaskletStep to be COMPLETED. Otherwise if the business process throws some exception, TaskletStep is FAILED.

    One slave tasklet step is totally independent of the other. So one tasklet step may have a FAILED status, while its sibling may have a COMPLETED status.

    And as usual partition step will have a status based on the aggregation of the slave steps.

    Now, I want to implement the stop functionality.
    So I tried JobOperator:stop().

    1) Inside TaskletStep:doExecute(), once the call to tasklet.execute() returned, there is a call getJobRepository().update(stepExecution).
    Inside getJobRepository().update(), if the jobExecution is STOPPING, the stepExuection is set as terminateOnly.
    Is this correct? Because, we have already completed the actual work within the tasklet.execute() itself. Now what is the point in making the step execution as terminateOnly and marking it as STOPPED.
    Additionally, if we restart the job, this step execution will again get picked up, even if we had already completed the actual work previous time itself.

    2) Again inside TaskletStep:doExecute(), there is a call to interruptionPolicy.checkInterrupted(...). Is this really needed, since we have already done the real work?
    Now even if we want to call the checkInterrupted(), shouldn't we be checking the current status of stepexecution before throwing a JobInterruptedException.


    Thanks in Advance!

  • #2
    Originally posted by Devadasan View Post
    Now, I want to implement the stop functionality.
    So I tried JobOperator:stop().
    I'm not sure if you said does this work or not? I'm guessing not, otherwise you wouldn't be asking questions, but it wasn't really clear what the issue was. Can you make that a bit clearer?

    I think the two questions you asked both show perhaps that you had overlooked the fact that not all tasklets are executed only once? If a tasklet is executed many times in a step, then it makes sense to check for interruptions after each execution. Does that help? Or did I misunderstand your confusion?


    • #3
      Thanks for the quick reply. Apologies if I was not clear enough.
      stop() didn't work the way I expected.
      MasterStepExecution is splitted into PartitionStepExecutions.
      TaskletStep.doExecute(stepexecution) is called for each of these PartitionStepExecution.
      So essentially TaskletStep.doExecute(stepexecution) , and hence the corresponding tasklet.execute() is called exactly once per stepexecution.

      This is the situation of my doubt, if its right to check the interruption after the each execution.