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?

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

Reply via email to