Tomcat does not shutdown correctly when using @Scheduled [SPR-7231]

[spring-projects-issues]

Jens Göring opened SPR-7231 and commented

When using @Scheduled, Tomcat will freeze on shutdown when using Linux. The problem seems to be that ConcurrentTaskScheduler creates an ScheduledExecutorService that uses non-daemon threads which prevent Tomcat to shutdown. This bug is similar to #11566, but not the same, because I already have the fixed version and the code from the fix is never executed in my application.

I guess the difference is that I use @Scheduled. I attached an code example which is pretty much the same as in http://blog.springsource.com/2010/01/05/task-scheduling-simplifications-in-spring-3-0/

When this application is deployed to Tomcat, and Tomcat is than stopped, Tomcat freezes. I attached a stacktrace where the non-daemon timer thread can be identified.

A solution might be to add this to ScheduledTaskRegistrar.destroy():

if (this.taskScheduler instanceof DisposableBean) {
     ((DisposableBean)this.taskScheduler).destroy();
}

(which is similar to the fix of #11566)

And make ConcurrentTaskScheduler implement DisposableBean:

public void destroy() throws Exception {
     this.scheduledExecutor.shutdown();
}

These changes fix the problem for me.

Please let me know if you see another workaround but to not using @Scheduled or patching Spring.

---

Jens Göring

---

Affects: 3.0.2

Attachments:

• stacktrace.txt (9.45 kB)
• test.zip (3.68 kB)

Issue Links:

• Tomcat does not shutdown correctly when using task:scheduled-taks [SPR-6901] #11566 Tomcat does not shutdown correctly when using task:scheduled-taks

[spring-projects-issues]

Juergen Hoeller commented

Good catch! I've revised ScheduledTaskRegistrar to call shutdownNow() on any default executor that it happens to use. Since ConcurrentTaskScheduler is supposed to be simple adapter for an existing Executor with an external lifecycle, we're not calling shutdownNow() there but rather in ScheduledTaskRegistrar itself - specifically for a default executor.

This will be available in tonight's 3.0.3 snapshot. As a workaround for the time being, specifying an externally configured scheduler bean should avoid this problem: The lifecycle is then up to that external bean in any case.

Juergen

[spring-projects-issues]

Jens Göring commented

Thanks for the quick reaction and workaround suggestion!

---

Jens Göring

[spring-projects-issues]

Jens Göring commented

I can confirm that 3.0.3 solves my original problem, thx for the fix!

---

Jens Göring