[External] : Re: Potential bug in HttpClientImpl: Thread pool rejection causes permanent client failure
Daniel Fuchs
daniel.fuchs at oracle.com
Thu Jun 19 17:56:15 UTC 2025
Hi David,
On 19/06/2025 18:08, David Nadeau wrote:
> I do want to follow up on the expected behavior of HttpClient in this case.
>
> If this kind of catastrophic failure within the HttpClient when using
> ThreadPools with bounded queues is falling within the expected behaviors
> of the HttpClient, then I believe it should be made explicitly clear on
> the HttpClient.Builder.executor method javadoc, that ThreadPools with
> bounded queues are not supported, and can lead to unrecoverable client
> failure if used.
>
This is a fair point.
We should add an implNote about how the client uses its executor.
>
> Why is it that tasks need to be executed? Dropping work can be an acceptable means of backpressure for a threadpool. Are there some tasks that the HttpClient submits to this delegate threadpool which are essential for the client to continue behaving correctly? And dropping such a task could cause the client to continue working, but in a potentially broken way?
Tasks submitted to the executor may include for instance,
processing data available for a given stream, completing
a BodySubscriber, etc... So they do need to be executed at
some point.
We have some tests that configure the HttpClient with small
thread pools (single threaded executor, or executor running
inline), but to use these you need to make sure that the
BodySubscribers/BodyPublishers you use will not make blocking
operations - as that could end up blocking the one thread available
to the client when invoking methods on these.
By design the tasks that the client submit should not block,
but they can invoke methods on BodyPublishers/BodySubscribers,
and some of these - like BodyPublishers.ofInputStream, or custom
body publishers or body handlers, may end up performing blocking
operations from tasks submitted to the executor.
In our plan for the future is evaluating to switch to using
VirtualThread executors by default, and that may alleviate
some of those issues.
You are raising an interesting point with your scenario though,
and I will need to think about it some more. At the moment though,
I don't think there's an immediate solution, except for instance,
delegating to the FJP.
best regards,
-- daniel
More information about the net-dev
mailing list