hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (HTTPCLIENT-1083) HttpClient.execute should close connection rather than call consumeContent
Date Thu, 05 May 2011 15:03:04 GMT

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Oleg Kalnichevski resolved HTTPCLIENT-1083.

    Resolution: Not A Problem


In _general_, I do not think we can assume in case of an exception it is cheaper to close
the connection than trying to consume the remaining content. For instance, BasicResponseHandler
shipped with HttpClient throws an I/O exception whenever it encounters a non-2xx response.
It would be unreasonable to drop the underlying connection (which may be perfectly reusable)
only because the server responded with a 3xx, 4xx, or 5xx status code. Another point to take
into consideration is that establishing a new SSL connection is massively more expensive than
keeping an existing one alive.

In your _particular_ case, since you have some special requirements specific to your application
you should really consider managing response entities within your application code instead
of using response handlers.


> HttpClient.execute should close connection rather than call consumeContent
> --------------------------------------------------------------------------
>                 Key: HTTPCLIENT-1083
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1083
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>    Affects Versions: 4.1.1
>            Reporter: Stepan Koltsov
> HttpClient.execute(..., responseHandler) calls consumeContent on error.
> This is inappropriate. If we are processing 1Gb files and responseHandler fails (throws
an exception) somewhere at the beginning of the file, HttpClient calls consumeContent, and
we have to wait until this 1Gb file transferred over the network. Even worse, if server is
stuck, and callback thrown exception (or quietly returned after examining first 10 bytes of
response), we have to wait for read timeout.
> I think connection should be just closed on error (only if the end of the response stream
is not yet reached).
> Moreover I think that connection should be also closed if responseHandler completed successfully
(and response is not fully read).
> And anyway, reopening a connection must be no more expensive than downloading the rest
of the response message.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message