Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
5.1.3
-
None
Description
My assumption is that closing an entity should have the same behavior as closing the entity.getContent() inputstream.
Given a streaming response, calling HttpEntity.close doesn't handle connection management pieces (interactions with the ExecRuntime) because ResponseEntityProxy wraps getContent and writeTo, however it does not override the close implementation inherited from HttpEntityWrapper.
In practice, this may mean that calling HttpEntity.close instead of consuming the contents doesn't return the connection to the pool, or in my case, calling CloseableHttpResponse.close results in execRuntime.disconnectEndpoint(); after the entity has been drained within its own close, however the connection is still closed.
I think we want to make either one of the following changes:
1. HttpEntity.close() provides the same behavior as HttpEntity.getContent().close(), draining the response (which we already do) and returning the connection for reuse
2. HttpEntity.close() does not read the full response, closing it immediately. I think I'd prefer to avoid this approach given that much of our code assumes close leaves a connection in a reusable state.
Separately, it may be helpful to provide a strategy interface to allow for more specific handling of connection closure prior to exhaustion of bytes. The current strategy of draining the full response is ideal in most scenarios, however after a certain amount of additional data, we may be better off closing the connection. I suspect part of the issue in this case is that we seem to expect subtly different behavior between CloseableHttpResponse.close and EntityUtils.consume(response.getEntity()).