Add configuration property "spring.task.execution.pool.shutdown.accept-tasks-after-context-close"

[quaff]

ExecutorConfigurationSupport::setAcceptTasksAfterContextClose is introduced since Spring Framework 6.1

[wilkinsona]

Thanks for the PR, @quaff.

We may need to find another location for this new property. The other two shutdown.* properties can be applied to both SimpleAsyncTaskExecutor and ThreadPoolTaskExecutor but this new one only applies to the latter. As such, it may be misleading when configured here. Perhaps we should introduce a pool-specific shutdown group and move it there.

Alternatively, I wonder if it would make sense for Framework to support this behavior with SimpleAsyncTaskExecutor? We'll discuss it with the Framework team.

[wilkinsona]

From @jhoeller:

That property is indeed new for the thread pool variants based on java.util.concurrent. I see it as specifically purposed for thread pools and in particular the ScheduledExecutorService variants where the effect goes beyond not accepting user tasks anymore: It's primarily about cancelling all registered triggers and recurring tasks there, in preparation for a complete shutdown, which is the new default behavior for a graceful shutdown there now. The acceptTasksAfterContextClose flag is effectively an escape hatch for restoring the old behavior there, starting the shutdown procedure at the last moment even for triggers etc.

On SimpleAsyncTaskExecutor and also SimpleAsyncTaskScheduler, there never was such old behavior, so I don't see a need for such a flag there. SimpleAsyncTaskScheduler always starts the shutdown procedure of the scheduler thread when the context closes (equivalent to acceptTasksAfterContextClose=false but without an escape hatch). SimpleAsyncTaskExecutor does not really have a concept of an early shutdown signal since it does not have a shared thread - just the common enforcement of individual task termination if taskTerminationTimeout has been set.
All in all, from a Boot perspective, I'd consider acceptTasksAfterContextClose as an escape hatch that is specific to the thread pool variants.

It's also worth noting that the virtual thread based variants have a different notion of task rejection: The thread pool variants reject the acceptance of a task into their task queue (a backlog that may be quite populated already), whereas the virtual threads only do immediate execution and therefore only actually reject tasks on ultimate termination. That's another reason why the thread pool variants need to start rejecting early on context close for a graceful shutdown, in addition to the trigger/recurring task management.

Given the above, I think the configuration property should be spring.task.execution.pool.accept-tasks-after-context-close or spring.task.execution.pool.shutdown.accept-tasks-after-context-close. I'm leaning towards the latter, despite there being only one shutdown property at the moment. It provides some symmetry with the spring.task.execution.shutdown.* properties and also provides a natural home for any pool-specific shutdown-related properties that we may want to add in the future.

[quaff]

Given the above, I think the configuration property should be spring.task.execution.pool.accept-tasks-after-context-close or spring.task.execution.pool.shutdown.accept-tasks-after-context-close. I'm leaning towards the latter, despite there being only one shutdown property at the moment. It provides some symmetry with the spring.task.execution.shutdown.* properties and also provides a natural home for any pool-specific shutdown-related properties that we may want to add in the future.

OK, I will amend it.

[quaff]

It's done, please review @wilkinsona

[mhalbritter]

Thank you very much!