HttpClient has no explicit way of releasing threads

[Rafael Winterhalter]

The issue would still exist as the selector thread is not spawned from this
executor and also lives until the outer reference is garbage collected. In
my case, this quickly resulted in a few hundred threads from a
parameterized test. Also, I think that its unlikely that a drive-by
instance would be initiated with an explicit instance.

I understand it's not easily solved or avoided. For now, an explicit
warning in the javadoc might be the most sensitive solution.

Remi Forax <forax at univ-mlv.fr> schrieb am Di., 10. Mai 2022, 15:39:

> ----- Original Message -----
> > From: "Rafael Winterhalter" <rafael.wth at gmail.com>
> > To: "core-libs-dev" <core-libs-dev at 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
>