Nested @Async annotations can block indefinitely [SPR-14490]

[spring-projects-issues]

Phil Webb opened SPR-14490 and commented

Originally raised on the Spring Boot issue tracker:

spring-projects/spring-boot#6429

—
here is an issue introduced in Spring 4.2.6.RELEASE (used by Spring Boot 1.3.4.RELEASE) which means that it is possible for @Async annotated method calls to become blocked. This happens when you have nested @Async annotated calls which use the default task executor, and you have a task executor defined in your application context (but not explicitly used).

I have created a proof of concept here https://github.com/foygl/spring-async-problem

I've only tested this with Spring Boot so I'm not sure if this is a wider Spring problem or just an issue with Spring Boot (although I suspect the former). I've replicated this in Spring Boot version 1.4.0.RC1 (i.e. Spring 4.3.1.RELEASE) so this problem still exists in the latest version.

Thanks
—

Using Spring Boot 1.3.3 with the following in the build script also shows the issue:

ext['spring.version'] = '4.2.6.RELEASE'

---

Affects: 4.2.6

Issue Links:

• Regression: Early instantiation of a bean prevents proxying for @Async in 4.2.x but works in 4.1.x [SPR-14030] #18602 Regression: Early instantiation of a bean prevents proxying for @Async in 4.2.x but works in 4.1.x

[spring-projects-issues]

Stéphane Nicoll commented

Maybe related to #18602? Looking at it now.

[spring-projects-issues]

Stéphane Nicoll commented

There is something I am not sure I understand. It looks like this commit is the culprit here. Running the attached sample (super useful, thank you!), I can see that return beanFactory.getBean(TaskExecutor.class); returns the following bean:

@Bean(name = "unusedTaskExecutor")
public Executor unusedTaskExecutor() {
    final SimpleAsyncTaskExecutor executor = new SimpleAsyncTaskExecutor();
    executor.setConcurrencyLimit(1);
    return executor;
}

While, previously, it wouldn't. If I revert to 4.2.5.RELEASE and I invoke beanFactory.getBean("unusedTaskExecutor") in the debugger prior to this check, I can reproduce the same error.

Could it be that by the time AsyncAnnotationBeanPostProcessor runs, getBean(Class<?> type) only works on the bean definition (that is Executor) while when we operate things lazily, the actual type of the bean is checked? I am actually surprised that we have such difference in the framework, that makes the following code quite broken IMO:

// Search for TaskExecutor bean... not plain Executor since that would
// match with ScheduledExecutorService as well, which is unusable for
// our purposes here. TaskExecutor is more clearly designed for it.
executorToUse = beanFactory.getBean(TaskExecutor.class);

Juergen Hoeller, thoughts?

[spring-projects-issues]

Juergen Hoeller commented

I'm afraid there's not much we can do here since it is inherently fragile to rely on a bean not getting detected just because of a dumbed-down @Bean return type declaration. We always use the most specific type available, and that is the instance type once a bean has been created. This may have unexpected effects depending on startup order if those types are not the same, but well, I don't see how we could do better (without causing other regressions).

My recommendation is simply not to rely on such arrangements: Always declare the most specific return type possible, and in this particular case, don't declare unused Executor beans that you expect to be ignored... Granted, this may have accidentally worked in 4.2.5 but it was fragile there as well. So from my perspective, 4.2.6 is not causing a regression against an intended scenario here but rather just exposes a weakness that existed in that setup before.

That said, I guess we should document our default executor choices more explicitly. I would not actually recommend relying on such a default executor fallback in anything but a quick prototype, but point taken, we should document the defaults so that an explicit executor setup (as always recommended) can mimic the default settings if desired.