We are mixing spring-integration and the scheduling capabilities from spring-boot using:
@SpringBootApplication
@EnableIntegration
@IntegrationComponentScan
@EnableConfigurationProperties
@EnableScheduling
public class MyApplication {
...
}
@EnableScheduling
creates a bean named "taskScheduler" which is then used by spring-integration:
public abstract class IntegrationContextUtils {
public static final String TASK_SCHEDULER_BEAN_NAME = "taskScheduler";
...
}
private void registerTaskScheduler() {
if (!this.beanFactory.containsBean(IntegrationContextUtils.TASK_SCHEDULER_BEAN_NAME)) {
...
this.registry.registerBeanDefinition(IntegrationContextUtils.TASK_SCHEDULER_BEAN_NAME, scheduler);
}
}
Problem is, the default poolSize for spring-integration is 10 (which value is needed as we encounter starvation) while the default for spring-boot is 1 (which we also need to avoid concurrency in our scheduled processes).
Questions:
Thanks for your answers
The behviour and logic is correct. And expectations from the convention-on-configuration from Spring Boot perspective is also correct. Only what you miss that @EnableScheduling
is not a Spring Boot feature, but rather Spring Framework native: https://docs.spring.io/spring-framework/docs/current/reference/html/integration.html#scheduling. Spring Boot jsut give us an extra freedom of configuration some beans on the matter. So, we just need to rely on its auto-configuration.
If auto-configuration doesn't fit your requirements, you always can provide your own configuration and override whenever it is necessary.
Looking to the @EnableScheduling
, its @Scheduled
hooks and appropriate TaskSchedulingAutoConfiguration
in Spring Boot, it is not so easy to override whatever you want to make Spring Integration happy at the same time. So, we should go a bit opposite direction and really override a Scheduler
for Spring Integration endpoints. Every single place where you use poller
, you also need to configure a custom Scheduler
instead of that auto-configured.