----- Original Message ----- > From: "Rafael Winterhalter" <rafael....@gmail.com> > To: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Sent: Monday, May 9, 2022 11:43:49 PM > Subject: HttpClient has no explicit way of releasing threads
> Hello, Hello, > > looking at thread dumps, I realized that the HttpClient implementation does > not offer an explicit way to release its threads. Currently, the client: > > 1. maintains a cached thread pool with a retention size of 60 seconds. If > many such clients are created for short lived application, these threads > pile up. > 2. has a selector thread that only shuts down if the outer "facade" > reference is collected via a weak reference. If an application is not > running GC, this can take a while. > > This is not a big problem but I have seen peaks with suddenly many, many > threads (in test code) where many HttpClients were created for single use > and I was wondering if it was ever considered to add a method for disposing > the threads explicitly? You can change the Executor (it's one parameter of the builder) to use whatever executors you want so you can shutdown that executor as you want. This should fixed (1). Also once you update to Java 19/21, it seems a good scenario to test the executor that spawn virtual threads instead of platform threads. > > Alternatively, it might be an option to add a method like > HttpClient.shared() which would return a singleton HttpClient (created on > the first call, collected if no reference is kept anymore but reused in the > meantime) to address such scenarios. I can of course add a singleton in my > test project but I find this a bit awkward as it is something to remember > and to repeat in all applications we maintain. Therefore, it might be > convenient to add such methods for tests that usually aim to be decoupled. > > Thanks for your consideration, > best regards, Rafael regards, Rémi
