Platform-http do not spawn useless threads

[Croway]

The previous implementation was creating 2 threads per request, the first one, created by spring framework via AsyncExecutionInterceptor, and the second one with CompletableFuture.runAsync.

This PR avoids the creation of the 2nd thread, this way, the behavior is like plain Spring Boot @Async. And the Apache Camel thread pool can be controlled via

spring.task.execution.pool.max-size=10
spring.task.execution.pool.core-size=10

While improving this behavior I faced an issue with the return object of the service method, in particular, as you can see from https://github.com/apache/camel-spring-boot/compare/main...Croway:suboptimal-thread-usage?expand=1#diff-7844a79d0aab67af46e8f0538438aa37f3c8b8afb04072724cc78fcf8acb17f5R84 the method still returns CompletableFuture, though I am not doing a runAsync or supplyAsync (the service method is already running asynchronously) and the return is CompletableFuture.completedFuture(null).

I tried using void instead of CompletableFuture, but I was getting the following error The request object has been recycled and is no longer associated with this facade when accessing the HttpServletRequest Object, I do not fully understand this behavior, maybe Spring expects a completable future.

[farrault]

I tried using void instead of CompletableFuture, but I was getting the following error The request object has been recycled and is no longer associated with this facade when accessing the HttpServletRequest Object, I do not fully understand this behavior, maybe Spring expects a completable future.

Hello @Croway
Spring MVC need to receive a CompletableFuture (or a DeferredResult ) in order to put the Http Request in async mode ( this specific behaviour is implemented in this class :
https://github.com/spring-projects/spring-framework/blob/main/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/method/annotation/DeferredResultMethodReturnValueHandler.java#L69 )

If not, my understanding is that the request is considered fully processed by the Web Server when the method returns and the request/response internal object are clear/reused by the WebServer (explaining the error message you got)

--

And as you may already have noticed, having a @Async annoted method returning a CompletableFuture.completedFuture(Object) is classic as stated in https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/scheduling/annotation/Async.html

--

That being said, may I ask why you preferred to keep the use of AsyncExecutionInterceptor instead of just keeping the CompletableFuture.runAsync here (and removing AsyncExecutionInterceptor) ?

Both seem fully equivalent to me in term of behaviour ( in particular : both returns a "real" CompletableFuture to Spring MVC representing a processing that is about to be executed inside the Spring Boot executor)
while the use of CompletableFuture.runAsync seems much simpler.

I find today that this was because of https://issues.apache.org/jira/browse/CAMEL-21318, that you introduced AsyncExecutionInterceptor in https://github.com/apache/camel-spring-boot/pull/1244/files
I need to admit, I don't understand what was your problem with Undertow ; but I don't see what characteristics AsyncExecutionInterceptor may have that CompletableFuture.runAsync(xxxx, executor) didn't have and would be needed to fix it. Did you spot exactly why it has fixed your problem ?

( Switching from the common ForkJoinPool to a Spring Boot thread executor in that PR was definitely useful though )

Regards
Fabien