Warn about use of SimpleAsyncTaskExecutor for async requests [SPR-16203]

[spring-projects-issues]

Rossen Stoyanchev opened SPR-16203 and commented

The Spring MVC Java config and XML namespace allow configuring an AsyncTaskExecutor originally used for java.util.concurrent.Callable return values and by default a SimpleAsyncTaskExecutor is used with the recommendation to configure a task executor with a thread pool for use under load. 

Now that the same executor is also used for blocking writes when streaming with Flux or Observable, we should warn more proactively about this in the logs. 

---

Affects: 5.0.1

Issue Links:

• Support for autowire-candidate with @Bean [SPR-16204] #20752 Support for autowire-candidate with @Bean ("depends on")
• WebSocketConfigurationSupport.defaultSockJsTaskScheduler adds NoOpScheduler to context that is not usable in any way [SPR-16189] #20737 WebSocketConfigurationSupport.defaultSockJsTaskScheduler adds NoOpScheduler to context that is not usable in any way
• [doc] Update documentation on WebAsyncManager thread pool [SPR-16397] #20943 [doc] Update documentation on WebAsyncManager thread pool

Referenced from: commits 4b861ae, 7b3a72f, 7ea8ecb

[spring-projects-issues]

Rossen Stoyanchev commented

In the mean time applications can use WebMvcConfigurer#configureAsyncSupport to customize the thread pool.

[spring-projects-issues]

Rossen Stoyanchev commented

Adding 5.0.8 since this is a one-time warning in the logs.

[spring-projects-issues]

Michal Domagala commented

Could you clarify whether or not WebMvcConfigurer#configureAsyncSupport is solution or workaround? I can't find any commit nor Jira ticket for more elegant configuration

[spring-projects-issues]

Rossen Stoyanchev commented

To make sure we're talking about the same thing, this is only required when streaming to the response (e.g. Server-Sent Events, or application/stream+json) via Flux or io.reactivex.Observable where each event is written to the response via a blocking write to the ServletOutputStream. If you do that, on the first such response, a warnings appears in the logs, and plugging in a thread pool via WebMvcConfigurer#configureAsyncSupport is a solution, not a workaround.

This is not needed if you return a single value, such as Mono, or a Flux that's then collected to a Mono<List> which is the case for "application/json". In those cases a warning will not appear in the logs. So the warning can be used to check whether this is needed or not.

[spring-projects-issues]

Michal Domagala commented

Yes we are talking about streaming case. I would like to say that usually Spring Boot configures automatically required infrastructure, so need to configure ThreadPoolTaskExecutor from scratch is not typical.

If autoconfiguration is not possible, sample in documentation with default settings and/or good practice would be useful.

[spring-projects-issues]

Rossen Stoyanchev commented

I believe something is being added to Boot for this. Stéphane Nicoll?

[spring-projects-issues]

Stéphane Nicoll commented

As of today actually and available in the next milestone of Spring Boot 2.1, see #1563 for more details. There will be a TaskExecutorBuilder that you can use to easily build custom ThreadPoolTaskExecutor instances.

In the meantime, I am afraid you'll have to implement WebMvcConfigurer.

[spring-projects-issues]

Michal Domagala commented

Great, big thanks!