Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

waitForTasksToCompleteOnShutdown has no effect on tasks created with @Scheduled annotation #26482

Closed
stefanocke opened this issue Jan 31, 2021 · 3 comments
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: duplicate A duplicate of another issue

Comments

@stefanocke
Copy link

stefanocke commented Jan 31, 2021

Affects: 2.4.2 (and likely several previous releases)

Steps to reproduce:

  1. create a Spring Boot App with Spring Initializr
  2. @EnableScheduling at application class
  3. create @Scheduled method with Thread.sleep(60000)
  4. set spring.task.scheduling.shutdown.await-termination=true in application.properties
  5. start the application
  6. shutdown the application as soon as it is up

Expected Behavior
The task should not be interrupted, since spring.task.scheduling.shutdown.await-termination sets waitForTasksToCompleteOnShutdown to true on the TaskScheduler.

Actual Behavior
The task is interrupted the InterruptetException is logged.

More Details

  • When I manually schedule a task by something like scheduler.scheduleWithFixedDelay(), everything works as expected.
  • Debugging shows, that my @Scheduled task is interrupted by ScheduledAnnotationBeanPostProcessor.destroy()
  • I also noticed, that this might be intentionally. At least it was in 2016. See for instance SchedulingConfigurer's ScheduledTaskRegistrar should reliably shut down before TaskScheduler [SPR-15067] #19633.
  • However, it is at least very surprising, that waitForTasksToCompleteOnShutdown has not the excpected effect on tasks that are created in the somehow "most prominent way", the @Scheduled-Annotation. So IMHO it should either be fixed or documented.
  • Moreover, the behavior is inconsistent with @Async : if I create an @Async method and let it sleep for 60000ms while having spring.task.execution.shutdown.await-termination=true , everythinq works as expected: The async task is not interrupted on shutdown.

Note: When I say "shutdown" I mean to stop the application in Spring Tool Suite. In the log I see "Application shutdown requested.", so I assume I am testing an orderly shutdown here and not some corner case.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jan 31, 2021
@rstoyanchev rstoyanchev added the in: core Issues in core modules (aop, beans, core, context, expression) label Nov 10, 2021
@savinov
Copy link

savinov commented Sep 13, 2022

spring-boot PR related to the issue: spring-projects/spring-boot#15951

@mjaggard
Copy link

spring-boot PR related to the issue: spring-projects/spring-boot#15951

Related yes, but doesn't fix this issue - that PR was included in the releases where I've seen this behaviour.

savinov added a commit to savinov/spring-framework that referenced this issue Sep 14, 2022
1. build.gradle: comment io.spring.gradle-enterprise-conventions plugin
2. gradle.properties: set version=5.2.8.RELEASE-SHUTDOWN
3. ScheduledTaskRegistrar: shutdown taskScheduler in destroy()
4. ScheduledAnnotationBeanPostProcessor: do not cancel tasks in destroy()
savinov added a commit to savinov/spring-framework that referenced this issue Sep 14, 2022
…nShutdown is true

1. ScheduledTaskRegistrar: shutdown taskScheduler of ExecutorConfigurationSupport type in destroy()
2. ScheduledAnnotationBeanPostProcessor: do not cancel tasks in destroy(), taskRegistrar cancel them

Closes spring-projectsgh-26482
@snicoll snicoll self-assigned this Oct 2, 2023
@jhoeller jhoeller added status: duplicate A duplicate of another issue and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Nov 20, 2023
@jhoeller
Copy link
Contributor

This effectively duplicates #31019 and should therefore be addressed as of 6.0.12 / 5.3.30.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: duplicate A duplicate of another issue
Projects
None yet
7 participants