Sometimes you may want to delete a job that is scheduled, enqueued or already processing. This can be done easily via the Dashboard or even programmatically.
When the job is still enqueued or scheduled, things are easy - JobRunr changes the state of your Job to Deleted and all is well.
However, if the job is already processing, JobRunr will try to interrupt the thread that is currently processing the job.
Most of the JDK and third party libraries that do I/O will be able to listen for the thread interrupt signal and throw an
InterruptedException. As a primer on how Thread interruption works, I advise to read the Baeldung article on how to Handle InterruptedException in Java.
The purpose of the interrupt system is to provide a well-defined framework for allowing threads to interrupt tasks (potentially time-consuming ones) in other threads.
If you have code that can throw an
InterruptedException, things are easy - let JobRunr handle it:
If you decide to catch the
InterruptedException for some reason, it is important to either rethrow that same exception or interrupt the current thread itself.
If you don’t have any code that does I/O or it does not adhere to the standard interrupt framework, this means your code is basically uninterruptible and the job will keep running until it finishes (either succeeds or fails).
To solve this, you check in certain places of your own job method whether the thread is interrupted (as JobRunr will signal the thread that is running the job to interrupt when it is deleted).
More examples can be found in the JobRunr end-to-end tests.