When use @EnableWebSocket and @EnableScheduling at the same time, spring.task.sheduling* will not effect
After I debug a simple empty project, I found ScheduledTaskRegistrar always use localExecutor, because TaskSchedulingAutoConfiguration.taskScheduler(TaskSchedulerBuilder builder) not run.
I guess there are some conflict codes in WebSocketConfigurationSupport with TaskSchedulingAutoConfiguration
Comment From: wilkinsona
Thanks for the report. Unfortunately, I'm not sure what we can do about this. Even if you configure every SockJS registration with a TaskScheduler such that WebSocketConfigurationSupport's defaultSockJsTaskScheduler @Bean method returns null, the bean definition with the null bean still causes TaskSchedulingAutoConfiguration.taskScheduler to back off.
From a Spring Boot perspective at least, it's a bit unfortunate that the SockJS support uses a TaskScheduler bean which is a very general contract for something that's more specific and largely an implementation detail. It would be better (again, from Boot's perspective), if it used a more SockJS-specific type that then provided access to a TaskScheduler without having to expose the task scheduler itself as a bean.
I'll flag this for team attention so that we can discuss our options. @rstoyanchev, your input would be very welcome here as well please.
Comment From: rstoyanchev
defaultSockJsTaskScheduler is a bean for the ApplicationContext lifecycle. We could hide it completely to make it entirely an implementation detail but I suspect some applications will be impacted, so it doesn't seem ideal for 5.3.x. I'm wondering, if ConditionalOnMissingBean could ignore null beans? We have a few of those in Spring Framework Java configuration.
Comment From: snicoll
I'm wondering, if ConditionalOnMissingBean could ignore null beans?
Unfortunately, we won't be able to do that as conditions are evaluated on bean definitions, not instances and the only way for us to know would be to instantiate the bean.
Comment From: wilkinsona
Unfortunately, we don't think there's much we can do here in the Boot 2.x timeframe without a change in Framework that will probably have to wait till 6.0 (Boot 3.0). The simplest workaround that allows the spring.task.scheduling.* properties to be used is to declare the ThreadPoolTaskScheduler bean manually using the auto-configured builder:
@Bean
public ThreadPoolTaskScheduler taskScheduler(TaskSchedulerBuilder builder) {
return builder.build();
}
I've opened https://github.com/spring-projects/spring-framework/issues/27903 to track the Framework change. In the meantime, using the auto-configured builder to define your own ThreadPoolTaskScheduler is our recommendation.