Hi Eliot,
On 06/10/2021 18:22, Elliot Barlas wrote:
Thanks for the reply, Daniel.
This was an HTTP 1.1 connection. The code snippet for building the URL
and configuring the HttpClient was included in my previous email for
reference.
I can't make any claims about what was happening with packet
transmissions at the network level. It's entirely possible that the
destination maintained the TCP connection over an extended period
without fulfilling its obligation to send the body. But there must be a
way to guarantee completion for such scenarios. This was the function of
socket timeouts in the world of synchronous network APIs. In this new
asynchronous world, it looks like that might have been forgotten.
The alternative timeout code you mentioned addresses the problem in a
narrow sense, but it results in a resource leak. If the HTTP session is
abandoned at the application level via CompletableFuture timed wait,
there is still a footprint within HttpClient. Over time, socket handles,
callback objects, and other resources can accumulate with no visibility
to application code.
There should be no leak if you call CompletableFuture::cancel when
catching the TimeoutException as shown in my suggestion, and provided
you're on a recent JDK (16+). That should take care of reclaiming
all the resources linked to the exchange.
(that was taken care of by https://bugs.openjdk.java.net/browse/JDK-8245462)
If we had to implement a global timeout that's how we would do
it internally.
best regards,
-- daniel
