Consider virtual threads support for ThreadPoolTaskExecutor/ThreadPoolTaskScheduler

[bclozel]

As seen in spring-projects/spring-framework#33780 (comment), Spring Framework recently added virtual threads support for ThreadPoolTaskExecutor/ThreadPoolTaskScheduler. Java apps are not typically expected to pool virtual threads, but the use case there is about lifecycle management.

We should consider whether and how we want to support this use case, considering that:

• spring.threads.virtual.enabled=true enables virtual threads globally and our community expects it to embrace best practices
• so far, enabling this option switches to SimpleAsyncTaskScheduler/SimpleAsyncTaskExecutor and makes lots of configuration properties without effect. See the "Doesn't have an effect if virtual threads are enabled." mentions in the application properties docs

We should consider whether we want to support this use case through properties or through the existing customizers only.

[juliojgd]

I guess this is only about lifecycle management. If the purpose was enforcing limits (e.g. to avoid overwhelming other invoked services) maybe the choice would be a semaphore-based limiting executor, like the one at https://github.com/thunkware/virtual-threads-bridge?tab=readme-ov-file#virtual-threads-bridge implemented here https://github.com/thunkware/virtual-threads-bridge/blob/main/src/main/java/io/github/thunkware/vt/bridge/SemaphoreExecutor.java

This executor limits the number of simultaneous live VT's in the executor but without pooling them, following JDK team guidelines.

Perhaps not useful for this specific discussion but maybe for other Spring Fwk/Spring Boot locations.

[bclozel]

After discussing with the Boot and Framework teams, it seems the situation is not as clear cut.

We can't really switch all applications to ThreadPool variants as this would break expectations set so far. On the other hand, implementing lifecyle support for unmanaged tasks in the simple variant is not really solving the underlying problem; the required bits would make the simple variant really close to a threadpool variant.

I'm closing this issue for now in favor of a discussion here: spring-projects/spring-framework#33780 (comment)

Right now, Spring Boot apps that enabled virtual threads support should create their own ThreadPoolTaskExecutor bean using the auto-configured ThreadPoolTaskExecutorBuilder.

[quaff]

Right now, Spring Boot apps that enabled virtual threads support should create their own ThreadPoolTaskExecutor bean using the auto-configured ThreadPoolTaskExecutorBuilder.

I reworked #42913 to revert auto-configured parts, keep virtualThreads options for builders, should that PR be reopened? @bclozel