Spring Make it easier to execute a method on a particular type of thread

Affects: 6.1

With the introduction of virtual thread support, I anticipate that there will be an increased need for executing a method on a particular type of thread. Specifically, when a Servlet web server is using virtual threads for request handling, I anticipate a need to switch execution to a platform thread to avoid pinning of virtual threads caused by unavoidable synchronization in third-party code. This Tomcat mailing list discussion is one example of this problem.

This can be achieved today using an @Async annotated method that references a TaskExecutor that is using platform threads but it comes with a reasonably large amount of boiler plate as you have to move code into a separate method and work with the Future API.

To simplify things, I would like Framework to deal with the Future on my behalf so that I can write a "normal" method and have it automatically run on a thread from a particular task executor. There's prior art for this sort of functionality in Micronaut with its @ExecuteOn annotation. In a Spring app, I envisage that a similar annotation could be used on any method that's an entry point into the application such as a method on a @Controller.

Comment From: rstoyanchev

After an internal discussion, it would not be straight forward to implement this for Spring MVC if at all. In the very least it would require starting an async request, which is not expected here, and it might not be feasible to implement and support all controller method return types.

It is much easier to do this on WebFlux where switching threads can done seamlessly. On WebFlux, the benefit would be to get off the event loop and onto a thread pool for blocking. Note however that WebFlux does provide a mechanism for that. An annotation would make it easier, but we don't want to introduce a annotation with broad semantics if it can't actually be applied more broadly.

For now we are going to close this since JEP 491 is going to significantly address the original concern. If anything comes up in the future, we can look to address it with a more targeted solution, and also taking into account specific constraints with blocking handling in Spring MVC.