You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Doug Cutting (JIRA)" <ji...@apache.org> on 2012/06/11 22:45:43 UTC
[jira] [Updated] (AVRO-1069) HttpTransceiver never closes its
OutputStream, hinders java reuse of HTTP connections
[ https://issues.apache.org/jira/browse/AVRO-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Doug Cutting updated AVRO-1069:
-------------------------------
Attachment: AVRO-1069.patch
Here's a patch that addresses this.
> HttpTransceiver never closes its OutputStream, hinders java reuse of HTTP connections
> -------------------------------------------------------------------------------------
>
> Key: AVRO-1069
> URL: https://issues.apache.org/jira/browse/AVRO-1069
> Project: Avro
> Issue Type: Bug
> Components: java
> Reporter: Thomas Andrews
> Attachments: AVRO-1069.patch
>
>
> The class org.apache.avro.ipc.HttpTransceiver opens an OutputStream and never explicitly closes it. That seems like very bad behavior.
> I think you should also be closing the InputStream.
> In particular, Java has built-in the ability to keep HttpURLConnections open, and re-use them. You might think that not closing these streams would help Java in this effort, but actually, the streams are not the raw connections, but wrappers. The javadoc says: "Calling the close() methods on the InputStream or OutputStream of an HttpURLConnection after a request may free network resources associated with this instance but has no effect on any shared persistent connection."
> In other words, when you fail to close these streams, Java doesn't know you are done with the request, so it cannot re-use the connection. You only end up able to re-use the connection when the HttpURLConnection gets garbage-collected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira