-
Notifications
You must be signed in to change notification settings - Fork 41.2k
Make Scheduler consistent for Spring Integration #25109
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
Conversation
Related to https://stackoverflow.com/questions/65883496/mix-spring-integration-and-spring-scheduler Currently Spring Integration creates its own `TaskScheduler` bean if one doesn't exist in the ctx yet. When we add `@EnableScheduling`, Spring Boot auto-configures one for us, but this one comes with slightly different options then one in Spring Integration * Make Spring Integration auto-configuration to rely on the auto-configured `TaskScheduler`, so we will have a consistency when we use just Spring Integration or with `@Scheduled` methods and would rely on a single set of configuration properties for `TaskScheduler`. It does not make it consistent with what we have in Spring Integration by default, but Spring Boot may have its own opinion how to auto-configure target features
to avoid situations when `TaskSchedulingAutoConfiguration` is excluded from the auto-configuration
@artembilan thanks for following-up on that StackOverflow question here, this is very much appreciated. I was chatting with @wilkinsona as I wasn't sure how to treat this change. This discussion showed I was making quite a bit of assumptions so it would be helpful if we had a bit more details about what is going on. As I understand it, if you use SI in a Spring Boot app without I'd like to make sure that there isn't some other side effects such as SI running first and creating a scheduler, overwriting the one we were supposed to auto-configure. |
Your assumption is correct, Stéphane. Spring Integration creates a But since we are here in Spring Boot with its opinion based on the the convention-on-configuration this PR serves a couple goals:
In the end we will get aligned state independently if we use just Spring Integration or with Let me know if this is not clear and I'll try to describe other way! Thanks |
Alright cool. I am looking into Spring Integration's configuration support which uses 10 threads by default for the scheduler, using a We'll have to call this out in the release notes for 2.5. |
Currently Spring Integration creates its own `TaskScheduler` bean if one does not exist in the context yet. When we add `@EnableScheduling`, Spring Boot auto-configures one for us, but this one comes with slightly different options than the default in Spring Integration. This commit makes sure that Spring Integration reuses the auto-configured TaskScheduler if possible, regardless of the user opting-in for `@EnabledScheduling`. See gh-25109
Related to https://stackoverflow.com/questions/65883496/mix-spring-integration-and-spring-scheduler
Currently Spring Integration creates its own
TaskScheduler
beanif one doesn't exist in the ctx yet.
When we add
@EnableScheduling
, Spring Boot auto-configures onefor us, but this one comes with slightly different options
then one in Spring Integration
auto-configured
TaskScheduler
, so we will have a consistencywhen we use just Spring Integration or with
@Scheduled
methodsand would rely on a single set of configuration properties for
TaskScheduler
.It does not make it consistent with what we have in Spring Integration
by default, but Spring Boot may have its own opinion how to auto-configure
target features