HttpClient Send Method Guaranteed Completion

[Daniel Fuchs]

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