ScheduledExecutorService: cannot use scheduler.shutdown()

[nimo23]

I have an injected (Quarkus container managed) ScheduledExecutorService:

@Inject ScheduledExecutorService scheduler;

Everything is going well but I wonder how to remove tasks (runnables) from this scheduler? Since the scheduler contains different tasks, I can't just use scheduler.shutdown(); (By the way, since the scheduler is a container-managed version, I would also terminate all other tasks (not only mine) that use this scheduler - which probably wouldn't be good, or?).

I tried casting the ScheduledExecutorService to ScheduledThreadPoolExecutor to have the following methods available:

// I just want to completely remove one specific task from the scheduler
scheduledFuture.cancel(false); // my ScheduledFuture
// remove the task from the queue completly
((ScheduledThreadPoolExecutor) scheduler).remove(myRunnableTask);
((ScheduledThreadPoolExecutor) scheduler).setRemoveOnCancelPolicy(true);
((ScheduledThreadPoolExecutor) scheduler).purge();

However, Quarkus ScheduledExecutorService cannot be cast to ScheduledThreadPoolExecutor as it's not a subclass of this. Is there another way to remove a task from the schedule without the use of scheduler.shutdown();?

[quarkus-bot[bot]]

/cc @manovotn (scheduler), @mkouba (scheduler)

[manovotn]

(By the way, since the scheduler is a container-managed version, I would also terminate all other tasks (not only mine) that use this scheduler - which probably wouldn't be good, or?).

Yes, it's not a good idea to manually invoke shutdown() - I am not even sure Quarkus lets you do that?

I am not sure how to remove tasks as runnables (@mkouba might know more) but one other way might be through Scheduler interface - it has a simple implementation that you can obtain via @Inject Scheduler and allows you to schedule/pause/resume/unschedule jobs based on their string id.

[nimo23]

but one other way might be through Scheduler interface

Thanks, but I really need to use ScheduledExecutorService.

In Quarkus, there should be a way to programmatically remove tasks from ScheduledExecutorService, especially when using shutdown() is not allowed. If not, the usage of ScheduledExecutorService in Quarkus will be low if the user cannot even delete their tasks from the queue.

Maybe it would be possible to cast ScheduledExecutorService to another object which provides such methods?

[mkouba]

AFAIK the default ScheduledExecutorService in Quarkus is based on org.jboss.threads.EnhancedQueueExecutor. I'm not sure what's the policy applied when the ScheduledFuture#cancel() method is called but I would expect that the task is removed from the queue...

CC @dmlloyd

[nimo23]

but I would expect that the task is removed from the queue...

Yes, I would expect that too, but actually that's not the case. The task remains in the queue.

[dmlloyd]

Cancelling a task keeps a marker in the queue, but this marker is small. What problem are you trying to solve by removing the task from the queue?

[nimo23]

Unfortunately, org.jboss.threads.EnhancedQueueExecutor or its interface org.jboss.threads.management.ManageableThreadPoolExecutorService does not provide methods to delete tasks from the queue. Using "myScheduledFuture.cancel(false);" just cancels the actual task and runs it again on the next schedule, so unfortunately it won't be removed from the queue.

[dmlloyd]

If your task was run with scheduleAtFixedRate or scheduleWithFixedDelay, then cancelling the task via its ScheduledFuture is expected to prevent it from re-running per that API contract. If this is not the case then you have found a bug.

[nimo23]

@dmlloyd yes, indeed. It's a bug. The same code works in wildfly (using the ManagedExecutorService), i.e. in wildfly calling myScheduledFuture.cancel(false); does remove myScheduledFuture from the queue, but in Quarkus it incorrectly stays in the queue.

I created an issue with a reproducer: #39746

[mkouba]

I think that you misunderstood @dmlloyd's reply - cancelling the task will prevent it from re-running but the task stays in the queue.

[dmlloyd]

That is correct. In fact as far as you are concerned, there might not even be a queue - that's an implementation detail. For example I could implement a scheduled executor (poorly) by creating a new thread for each task which sleeps until its elapsed time occurs. In this case, there is no queue (other than the one that the OS itself might or might not use for scheduling threads).

So I ask again: is the task incorrectly being re-run? Or, is there some other observable effect that you're attributing to the presence of your task in a "queue" which is detrimental in some way?

[dmlloyd]

While attempting to get to the actual issue, I uncovered jboss/jboss-threads#163 which I think explains the reproducer's behavior.

[nimo23]

While attempting to get to the actual issue, I uncovered jboss/jboss-threads#163 which I think explains the reproducer's behavior.

@dmlloyd Yes, to summarize the problem: calling ScheduledFuture#cancel() should prevent it from running again in the future - that is not the case at the moment and that is exactly what the problem is about.