I'm experimenting with virtual threads, and I noti...

# http4k

[Andrew O'Hara]

I'm experimenting with virtual threads, and I noticed that the JavaHttpClient has a thread pool too. The javadocs say it's used for asynchronous or "dependent" tasks, and even if those capabilities aren't being used, they still leave a memory footprint, and most likely a cold-start penalty too (We've noticed the Java8HttpClient has superior cold-start performance on AWS Lambda). I'm currently trying to minimize the memory footprint of my ECS services to pack as many tasks as possible onto one host, so every MB of memory helps.

Has a LoomJavaHttpClient been evaluated and dismissed? Or is this just an oversight?

Actually, on second thought, I think the threads I found were for the official v2 aws sdk. I'm not even sure if I can easily override its executor. Guess I'll have to upgrade this service to http4k-connect!

[dave]

Nope - we haven't even thought about a JavaLoomHttpClient so it's a total oversight. Without looking at the API, I wonder if it's easier to inject the threadpool/executor on construction than have an entirely new client 🤷 .

The Java8HttpClient is quicker because there's no setup or threadpool at all - so it's perfect for Lambda's because of the model.

🙂

[dave]

Actually, on second thought, I think the threads I found were for the official v2 aws sdk. I'm not even sure if I can easily override its executor. Guess I'll have to upgrade this service to http4k-connect

This is the way 😉

[Andrew O'Hara]

I'm still not entirely sure the JavaHttpClient actually spawns any threads unless needed. It's fairly easy to inject the executor on init, but you can't use the precanned client.