[
https://issues.apache.org/jira/browse/HTTPCLIENT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553093#comment-17553093
]
ASF subversion and git services commented on HTTPCLIENT-2221:
-------------------------------------------------------------
Commit df69bd29028f50743c4a2ede4a66a663721906cd in httpcomponents-client's
branch refs/heads/5.1.x from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=df69bd290 ]
HTTPCLIENT-2221 Closing a classic response/entity allows connection reuse
Previously, a partially consumed response body closed via
CloseableHttpResponse.close or HttpEntity.close would fully consume
remaining bytes (via close), however it would not release the
connection for reuse.
If CloseableHttpResponse.close was called, it would follow the close
with a discard/disconnect, however if only the entity was closed,
the connection would remain in a checked-out (leaked) state.
Now, we take advantage of the fact that closing a response stream
on any reusable connection is required to drain bytes on closure.
Failures are detected by writeTo and the stream returned by
getContent, so we can be confident that we will not return a
broken connection to the pool.
> Differences between HttpEntity.close() and HttpEntity.getContent().close()
> --------------------------------------------------------------------------
>
> Key: HTTPCLIENT-2221
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2221
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 5.1.3
> Reporter: Carter Kozak
> Assignee: Carter Kozak
> Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 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())}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
