Provide method for stopping Batch 5 Jobs upon user request #5990
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the previous release of SCDF we used the JsrJobOperator to stop job executions. The 2 stages of stopping jobs is as follows: 1) Sets the Batch Status of the job execution to STOPPING. This signals to Spring Batch to stop execution at the next step. 2) If the Job is a StepLocator it will go through each of the StoppableTasklets and stop them. Since Dataflow never deals with a Job directly, it never executed the 2nd stage. Meaning the Job is in the application that SCDF launched, not SCDF itself. So when using Batch 4.x it was just a quick check of the JobRegistry to retrieve the job, which was always empty since SCDF never deals with Jobs directly. But with Batch 5.x they loaded the Job Registry and attempted to retrieve the Job in a different way using the SimpleJobOperator. In the updated solution, SCDF doesn't use the SimpleJobOperator since SCDF doesn't have access to the StepLocator for the Job, nor does it use the JobRegistry and even if it did, it would always be empty. w
onobc
reviewed
Oct 16, 2024
...ver-core/src/main/java/org/springframework/cloud/dataflow/server/batch/SimpleJobService.java
Show resolved
Hide resolved
* Modify stopAll so that it calls stop() instead of using its own logic * Add Test for stopAll
onobc
reviewed
Oct 17, 2024
...ver-core/src/main/java/org/springframework/cloud/dataflow/server/batch/SimpleJobService.java
Outdated
Show resolved
Hide resolved
onobc
reviewed
Oct 17, 2024
...test/java/org/springframework/cloud/dataflow/server/batch/AbstractSimpleJobServiceTests.java
Outdated
Show resolved
Hide resolved
corneil
reviewed
Oct 17, 2024
| jobExecution = jobService.getJobExecution(jobExecution.getId()); | ||
| assertThat(jobExecution.isRunning()).isTrue(); | ||
| assertThat(jobExecution.getStatus()).isNotEqualTo(BatchStatus.STOPPING); | ||
| jobService.stop(jobExecution.getId()); | ||
| jobExecution = jobService.getJobExecution(jobExecution.getId()); | ||
| assertThat(jobExecution.getStatus()).isEqualTo(BatchStatus.STOPPED); | ||
| assertThat(jobExecution.getStatus()).isEqualTo(BatchStatus.STOPPING); |
There was a problem hiding this comment.
should we wait for STOPPED as well?
There was a problem hiding this comment.
STOPPED only occurs once the batch job has completed. In this test we are just testing that SCDF sets the state to STOPPING. We are not running real jobs here, just creating / modifying the state of the JobExecution.
Extract job stop code from stop(long) and place into stopJobExecution method. The stopJobExecution method will be used by stop(long) and stopAll.
Moved Job Stop Code from assert methods to the tests. Updated the JobExecution Create methods so that they verify that the job is not Stopping
onobc
reviewed
Oct 17, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the previous release of SCDF we used the JsrJobOperator to stop job executions. The 2 stages of stopping jobs is as follows:
Since Dataflow never deals with a Job directly, it never executed the 2nd stage. Meaning the Job is in the application that SCDF launched, not SCDF itself. So when using Batch 4.x it was just a quick check of the JobRegistry to retrieve the job, which was always empty since SCDF never deals with Jobs directly. But with Batch 5.x they loaded the Job Registry and attempted to retrieve the Job in a different way using the SimpleJobOperator. This caused a NPE when it tried to retrieve and determine if the Job was a StepLocator. In the updated solution, SCDF doesn't use the SimpleJobOperator since SCDF doesn't have access to the StepLocator for the Job, nor does it use the JobRegistry and even if it did, it would always be empty.
Resolves #5986