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

Comment From: snicoll

@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 @EnableScheduling then we don't auto-configre the scheduler but SI creates one. Is that a fair summary? And, if so, this PR would "only" fixes the situation where someone uses SI without @EnableScheduling?

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.

Comment From: artembilan

Your assumption is correct, Stéphane.

Spring Integration creates a TaskScheduler for its purpose in some BeanFactoryPostProcessor if there is no end-user provided yet: https://github.com/spring-projects/spring-integration/blob/master/spring-integration-core/src/main/java/org/springframework/integration/config/DefaultConfiguringBeanFactoryPostProcessor.java#L301.

But since we are here in Spring Boot with its opinion based on the the convention-on-configuration this PR serves a couple goals:

  1. Make sure that SI's TaskScheduler does not override an auto-configured one when @EnableScheduling is used. This really could be a problem when SI is auto-configured first, so the TaskSchedulingAutoConfiguration purpose is eliminated independently of the @EnableScheduling presence.
  2. Ensure that scheduling configuration properties can be used for SI purposes as well. At the moment end-user has to provide spring.integration.properties to override TaskScheduler options for SI even if it is about Spring Boot. Or he/she has to try making TaskSchedulingAutoConfiguration auto-configured first. but still @EnableScheduling must be there...

In the end we will get aligned state independently if we use just Spring Integration or with @EnableScheduling and users would have a single source of truth.

Let me know if this is not clear and I'll try to describe other way!

Thanks

Comment From: snicoll

Alright cool. I am looking into Spring Integration's configuration support which uses 10 threads by default for the scheduler, using a spring.integration.taskScheduler.poolSize property which, I am assuming, can be configured by the user.

We'll have to call this out in the release notes for 2.5.