Il 10/05/2022 15:39, Remi Forax ha scritto:
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
ter"
> > To: "core-libs-dev"
> > 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 implemen
On 10/05/2022 14:39, Remi Forax wrote:
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 ch
- Original Message -
> From: "Rafael Winterhalter"
> To: "core-libs-dev"
> 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 H
Thanks,
I created a shared client for now which solves my issue. I only stumbled
upon this as a build server increased its use of resources and the change
was that somebody had removed a third-party (closeable) HTTP client to
replace it with the JDK client. Unit tests often aim to be decoupled,
th
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
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 th
