Given the current WebClient API, it is possible to have:
In that case, we're consuming the response body completely; under the covers, reactor-netty will dispose the connection (close it or return it to the connection pool) as soon as the body has been consumed.
But we can also do this:
In that case, the body is not consumed, and the underlying client has no way of knowing that the connection should be closed. This can lead to issues with the connection pool, memory leaks, etc.
In the ClientConnector#connect method, before returning the `ClientHttpResponse`, we could do something like:
But unfortunately, this will close the connection too soon. The first example can be rewritten like:
With the flatMap operator, we wait until the Mono<ClientHttpResponse> is completed and proceed with the body. The completion triggers that doOnTerminate operator.
Reactor Netty is currently dealing with this in its API and considering the following changes:
With this type of changes, the response body Publisher is tied back to the lifecycle of the connection.
We need to revisit our current client API to make sure that the connection lifecycle can be properly managed for the underlying client library.