Skip to content

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

Closed
wants to merge 3 commits into from

Conversation

artembilan
Copy link
Member

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

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
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Feb 4, 2021
to avoid situations when `TaskSchedulingAutoConfiguration` is
excluded from the auto-configuration
@snicoll snicoll self-assigned this Feb 9, 2021
@snicoll
Copy link
Member

snicoll commented Feb 9, 2021

@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.

@snicoll snicoll added the status: waiting-for-feedback We need additional information before we can continue label Feb 9, 2021
@artembilan
Copy link
Member Author

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

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Feb 9, 2021
@snicoll snicoll added type: enhancement A general enhancement and removed status: feedback-provided Feedback has been provided status: waiting-for-triage An issue we've not yet triaged labels Feb 9, 2021
@snicoll snicoll added this to the 2.5.0-M2 milestone Feb 9, 2021
@snicoll
Copy link
Member

snicoll commented Feb 9, 2021

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.

@snicoll snicoll added the status: noteworthy A noteworthy issue to call out in the release notes label Feb 9, 2021
snicoll pushed a commit that referenced this pull request Feb 9, 2021
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
@snicoll snicoll closed this in c60e9c8 Feb 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: noteworthy A noteworthy issue to call out in the release notes type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants