Is it possible to kill a running job through the library?

[tomhillgreyridge]

Is there a way in db-scheduler to kill a single running task without needing to stop the entire scheduler?

I'm assuming that each job runs on a single thread so it would probably just need a way of getting hold of the running thread for an executing job and then being able to call Thread.interrupt on it. I can find the currently executing tasks using scheduler.currentlyExecuting but it doesn't appear to have a "kill" or "interrupt" method on it.

Alternatively, is there a way to stop the scheduler "instantly" regardless of the setting of shutdownMaxWait?

I'm basically thinking about a way to quickly deal with "runaway" jobs in an application without having to kill the entire application

[tomhillgreyridge]

Trying to cancel it by getting the TaskInstanceID just gives "Cannot use SchedulerClient to modify a task-instance that is currently executing"

[kagkarlsson]

There is no way to do that no, and I not sure it can be done. There is no guarantee the Thread is interruptable. What if it is not waiting? Rather than interrupt, what about setting a timeout?
If you want to guard against a loop taking too long to finish, you can solve that yourself, by regularly checking some external condition for each iteration (or similar).

[hana-krizova]

Hello kagkarlsson and tomhillgreyridge,

I have the same requirement from customers - sometimes user needs to kill a running job.

I think I can put this information (about the need to kill the job) into the database and react to this information in my code by terminating it correctly.

Could I store this information in the task data? Can be task data updated by the Scheduler without changing anything else?

It would be basically similar to the JdbcTaskRepository#replace method, but it would only modify the task data, nothing else.

Hana Křížová

[kagkarlsson]

Could I store this information in the task data? Can be task data updated by the Scheduler without changing anything else?

I don't think that is a good idea no. Would you store the thread-name? That is not known until after it was locked and I think unexpected things might happen if the update the record between lock and running the completionhandler.

[kagkarlsson]

You might have to maintain a mapping in your code taskinstance=>thread-id or something like that. Build it up at the start of the ExecutionHandler at which time the thread is known. (luckily we do not do async yet, in which case the thread might vary