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

Scheduling auto-configuration backs off with @EnableWebSocket #28449

Closed
lfz757077613 opened this issue Oct 26, 2021 · 4 comments
Closed

Scheduling auto-configuration backs off with @EnableWebSocket #28449

lfz757077613 opened this issue Oct 26, 2021 · 4 comments
Assignees
Labels
status: declined A suggestion or change that we don't feel we should currently apply type: bug A general bug

Comments

@lfz757077613
Copy link

lfz757077613 commented Oct 26, 2021

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

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Oct 26, 2021
@wilkinsona
Copy link
Member

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.

@wilkinsona wilkinsona added the for: team-attention An issue we'd like other members of the team to review label Oct 26, 2021
@snicoll snicoll changed the title spring.task.sheduling* not effect Scheduling auto-configuration backs off with @EnableWebSocket Oct 27, 2021
@rstoyanchev
Copy link
Contributor

rstoyanchev commented Oct 27, 2021

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.

@snicoll
Copy link
Member

snicoll commented Oct 27, 2021

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.

@wilkinsona
Copy link
Member

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 spring-projects/spring-framework#27903 to track the Framework change. In the meantime, using the auto-configured builder to define your own ThreadPoolTaskScheduler is our recommendation.

@wilkinsona wilkinsona added status: declined A suggestion or change that we don't feel we should currently apply type: bug A general bug and removed status: waiting-for-triage An issue we've not yet triaged labels Jan 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply type: bug A general bug
Projects
None yet
Development

No branches or pull requests

6 participants