Our team took the jump 5 years ago to use the Async Http Client 5 library in order to handle more concurrent requests. It has worked well but introduced complexities in troubleshooting, broke MDC / localstorage, and made our metrics provided have a hard time tracing our requests from start to end. We navigated all this but it took alot of extra coding and code that is disjointed, as you would expect from asynchronous programming.
Today... We are running on Jdk 25 and looking to embrace virtual threads. Based on what I've read about virtual threads, it seems sensible for us to revert to the classic/sync version of this library. We are super excited about the possibility of moving back to simpler stacktraces, code read-ability, etc, however, I wanted to make sure we were not shootihg our selves in the foot. IS THERE ANY REASON TO STAY ON ASYNC HTTP CLIENT 5, knowing we are running on jdk 25 with vthreads? >From my reading, with Virtual Threads, the Classic Sync version becomes just as efficient as the Async version because the "blocking" no longer wastes a heavy OS thread. The "Double Scheduling" Problem If you stay on the Async version while using Virtual Threads: - Your code runs on a Virtual Thread. - You call the Async client, which puts the request in a queue. - An I/O Thread (Platform Thread) picks it up and manages the network. When done, a Callback Thread triggers your logic. By moving to the Classic version, you remove those middle steps. The Virtual Thread handles the request from start to finish, calling the OS directly via the Synchronous API. It is cleaner, has less overhead, and makes your requests much easier to track in a profiler. Just need a sanity check please.
