On Fri, 2026-04-17 at 15:15 -0400, Patrick Barry wrote: > 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.
I have been saying it literally for decades: the async i/o model has no advantages over the classic i/o model unless one truly needs to maintain thousands of concurrent connections, which is rarely the case for client-side HTTP/1.1 transports. The async version of Apache HttpClient is better suited for special cases, for instance, when one needs to maintain thousands of open connections that stay idle most of the time. The classic version is the best all around choice as long as one does not need HTTP/2. HTTP/2 support is the reason to stay with the async version. Oleg PS: please subscribe to the list before posting. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
