HttpClient has no explicit way of releasing threads

[Daniel Fuchs]

Hi Rafael,

On 09/05/2022 22:43, Rafael Winterhalter wrote:
> 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?

I would consider it bad practice to create an HttpClient instance for
single usage; Ideally a client should be reused - provided that
the security context is the same. Creating an HttpClient involves
creating a thread pool, a selector, a selector manager thread,
potentially initializing an SSL context etc...

WRT to adding a method for disposing the HttpClient explicitly, then
yes - that's something that we could consider for a major
release. It would need to be carefully specified - especially WRT what
would be the effect of calling this method if some operations are still
in progress. Asynchronously closing objects that are still in use is
a notoriously thorny subject.
We might need something equivalent to what is defined for executor
services - that is - one variant that waits for all ongoing operations
to terminate before closing, and one that abruptly aborts any
on-going operation.

> 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.

An HttpClient is a kind of capability object so I don't think we want
to have a shared client in the Java API. That's something that
an application can easily implement at the application level if it
makes sense for the application.

A possibility to work around the thread peak issue is also for an
application to configure its own thread executor on the HttpClient.
If that makes sense for the application and if it is safe to do
so the executor can also be shared between several client.
It is then the responsibility of the application
to shutdown the executor when the clients are no longer in use.

> 
> Thanks for your consideration,
> best regards, Rafael

best regards,

-- daniel