You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Thomas Andrews (JIRA)" <ji...@apache.org> on 2012/04/20 23:19:33 UTC
[jira] [Created] (AVRO-1069) HttpTransceiver never closes its
OutputStream
Thomas Andrews created AVRO-1069:
------------------------------------
Summary: HttpTransceiver never closes its OutputStream
Key: AVRO-1069
URL: https://issues.apache.org/jira/browse/AVRO-1069
Project: Avro
Issue Type: Bug
Components: java
Reporter: Thomas Andrews
I'm not sure if this is the cause of my underlying problem, but the class org.apache.avro.ipc.HttpTransceiver opens an OutputStream and never explicitly closes it. That seems like very bad behavior, especially depending on whether the HttpURLConnection class holds onto the OutputStream or not - if it does, then potentially the Transceiver will never close the OutputStream.
The specific oddity I am seeing is related to Flume. I have an Flume agent and a client using a FlumeEventAvroServer with the Avro HttpTransceiver class.
Occasionally, when the Avro agent gets refreshed or otherwise reset, it fails with a BindException error.
Even rarer, but still often enough to cause concern, the client software holds onto something which blocks the Flume agent from rebinding to the port even when the Flume agent is restarted. Essentially, something is now "occupying" the port. It is my guess that it is the transceiver which has failed to close the OutputStream, but I'm not 100% sure.
I think you should also be closing the InputStream, as well.
--
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
[jira] [Updated] (AVRO-1069) HttpTransceiver never closes its
OutputStream, hinders java reuse of HTTP connections
Posted by "Doug Cutting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Doug Cutting updated AVRO-1069:
-------------------------------
Resolution: Fixed
Status: Resolved (was: Patch Available)
I committed 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
> Assignee: Doug Cutting
> Fix For: 1.7.1
>
> 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
[jira] [Commented] (AVRO-1069) HttpTransceiver never closes its
OutputStream
Posted by "Thomas Andrews (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263787#comment-13263787 ]
Thomas Andrews commented on AVRO-1069:
--------------------------------------
When I rolled my own transceiver which was a copy of HttpTransceiver with close() calls to the InputStream and OutputStream added, I got much better connection re-use in Java. Specifically, in load test with four streams sending requests to the server, using Avro's HttpTransceiver, I used "netstat" to see that there were anywhere from 3-4 sockets open to handle the requests, but when I used my custom transceiver, it used only one socket for all four streams.
Since Java (by default) has a maximum of 5 cached open connections, this means at slightly higher load, HttpTransceiver is going to be opening lots of one-shot sockets.
> HttpTransceiver never closes its OutputStream
> ---------------------------------------------
>
> Key: AVRO-1069
> URL: https://issues.apache.org/jira/browse/AVRO-1069
> Project: Avro
> Issue Type: Bug
> Components: java
> Reporter: Thomas Andrews
>
> I'm not sure if this is the cause of my underlying problem, but the class org.apache.avro.ipc.HttpTransceiver opens an OutputStream and never explicitly closes it. That seems like very bad behavior, especially depending on whether the HttpURLConnection class holds onto the OutputStream or not - if it does, then potentially the Transceiver will never close the OutputStream.
> The specific oddity I am seeing is related to Flume. I have a Flume agent listening on port 60000 and a client using a FlumeEventAvroServer with the Avro HttpTransceiver class.
> Occasionally, when the Avro agent gets refreshed or otherwise reset, it fails with a BindException error.
> Even rarer, but still often enough to cause concern, the client software holds onto something which blocks the Flume agent from rebinding to the port even when the Flume agent is restarted. Essentially, something is now "occupying" the port. It is my guess that it is the transceiver which has failed to close the OutputStream, but I'm not 100% sure.
> I think you should also be closing the InputStream, as well.
--
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
[jira] [Updated] (AVRO-1069) HttpTransceiver never closes its
OutputStream, hinders java reuse of HTTP connections
Posted by "Doug Cutting (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (AVRO-1069) HttpTransceiver never closes its
OutputStream
Posted by "Thomas Andrews (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Andrews updated AVRO-1069:
---------------------------------
Description:
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.
was:
I'm not sure if this is the cause of my underlying problem, but the class org.apache.avro.ipc.HttpTransceiver opens an OutputStream and never explicitly closes it. That seems like very bad behavior, especially depending on whether the HttpURLConnection class holds onto the OutputStream or not - if it does, then potentially the Transceiver will never close the OutputStream.
I think you should also be closing the InputStream, as well.
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.
> HttpTransceiver never closes its OutputStream
> ---------------------------------------------
>
> Key: AVRO-1069
> URL: https://issues.apache.org/jira/browse/AVRO-1069
> Project: Avro
> Issue Type: Bug
> Components: java
> Reporter: Thomas Andrews
>
> 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
[jira] [Updated] (AVRO-1069) HttpTransceiver never closes its
OutputStream
Posted by "Thomas Andrews (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Andrews updated AVRO-1069:
---------------------------------
Description:
I'm not sure if this is the cause of my underlying problem, but the class org.apache.avro.ipc.HttpTransceiver opens an OutputStream and never explicitly closes it. That seems like very bad behavior, especially depending on whether the HttpURLConnection class holds onto the OutputStream or not - if it does, then potentially the Transceiver will never close the OutputStream.
I think you should also be closing the InputStream, as well.
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.
was:
I'm not sure if this is the cause of my underlying problem, but the class org.apache.avro.ipc.HttpTransceiver opens an OutputStream and never explicitly closes it. That seems like very bad behavior, especially depending on whether the HttpURLConnection class holds onto the OutputStream or not - if it does, then potentially the Transceiver will never close the OutputStream.
The specific oddity I am seeing is related to Flume. I have a Flume agent listening on port 60000 and a client using a FlumeEventAvroServer with the Avro HttpTransceiver class.
Occasionally, when the Avro agent gets refreshed or otherwise reset, it fails with a BindException error.
Even rarer, but still often enough to cause concern, the client software holds onto something which blocks the Flume agent from rebinding to the port even when the Flume agent is restarted. Essentially, something is now "occupying" the port. It is my guess that it is the transceiver which has failed to close the OutputStream, but I'm not 100% sure.
I think you should also be closing the InputStream, as well.
> HttpTransceiver never closes its OutputStream
> ---------------------------------------------
>
> Key: AVRO-1069
> URL: https://issues.apache.org/jira/browse/AVRO-1069
> Project: Avro
> Issue Type: Bug
> Components: java
> Reporter: Thomas Andrews
>
> I'm not sure if this is the cause of my underlying problem, but the class org.apache.avro.ipc.HttpTransceiver opens an OutputStream and never explicitly closes it. That seems like very bad behavior, especially depending on whether the HttpURLConnection class holds onto the OutputStream or not - if it does, then potentially the Transceiver will never close the OutputStream.
> I think you should also be closing the InputStream, as well.
> 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
[jira] [Updated] (AVRO-1069) HttpTransceiver never closes its
OutputStream, hinders java reuse of HTTP connections
Posted by "Doug Cutting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Doug Cutting updated AVRO-1069:
-------------------------------
Fix Version/s: 1.7.1
Assignee: Doug Cutting
Status: Patch Available (was: Open)
I'll commit this soon unless there are objections.
> 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
> Assignee: Doug Cutting
> Fix For: 1.7.1
>
> 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
[jira] [Updated] (AVRO-1069) HttpTransceiver never closes its
OutputStream
Posted by "Thomas Andrews (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Andrews updated AVRO-1069:
---------------------------------
Description:
I'm not sure if this is the cause of my underlying problem, but the class org.apache.avro.ipc.HttpTransceiver opens an OutputStream and never explicitly closes it. That seems like very bad behavior, especially depending on whether the HttpURLConnection class holds onto the OutputStream or not - if it does, then potentially the Transceiver will never close the OutputStream.
The specific oddity I am seeing is related to Flume. I have a Flume agent listening on port 60000 and a client using a FlumeEventAvroServer with the Avro HttpTransceiver class.
Occasionally, when the Avro agent gets refreshed or otherwise reset, it fails with a BindException error.
Even rarer, but still often enough to cause concern, the client software holds onto something which blocks the Flume agent from rebinding to the port even when the Flume agent is restarted. Essentially, something is now "occupying" the port. It is my guess that it is the transceiver which has failed to close the OutputStream, but I'm not 100% sure.
I think you should also be closing the InputStream, as well.
was:
I'm not sure if this is the cause of my underlying problem, but the class org.apache.avro.ipc.HttpTransceiver opens an OutputStream and never explicitly closes it. That seems like very bad behavior, especially depending on whether the HttpURLConnection class holds onto the OutputStream or not - if it does, then potentially the Transceiver will never close the OutputStream.
The specific oddity I am seeing is related to Flume. I have an Flume agent and a client using a FlumeEventAvroServer with the Avro HttpTransceiver class.
Occasionally, when the Avro agent gets refreshed or otherwise reset, it fails with a BindException error.
Even rarer, but still often enough to cause concern, the client software holds onto something which blocks the Flume agent from rebinding to the port even when the Flume agent is restarted. Essentially, something is now "occupying" the port. It is my guess that it is the transceiver which has failed to close the OutputStream, but I'm not 100% sure.
I think you should also be closing the InputStream, as well.
> HttpTransceiver never closes its OutputStream
> ---------------------------------------------
>
> Key: AVRO-1069
> URL: https://issues.apache.org/jira/browse/AVRO-1069
> Project: Avro
> Issue Type: Bug
> Components: java
> Reporter: Thomas Andrews
>
> I'm not sure if this is the cause of my underlying problem, but the class org.apache.avro.ipc.HttpTransceiver opens an OutputStream and never explicitly closes it. That seems like very bad behavior, especially depending on whether the HttpURLConnection class holds onto the OutputStream or not - if it does, then potentially the Transceiver will never close the OutputStream.
> The specific oddity I am seeing is related to Flume. I have a Flume agent listening on port 60000 and a client using a FlumeEventAvroServer with the Avro HttpTransceiver class.
> Occasionally, when the Avro agent gets refreshed or otherwise reset, it fails with a BindException error.
> Even rarer, but still often enough to cause concern, the client software holds onto something which blocks the Flume agent from rebinding to the port even when the Flume agent is restarted. Essentially, something is now "occupying" the port. It is my guess that it is the transceiver which has failed to close the OutputStream, but I'm not 100% sure.
> I think you should also be closing the InputStream, as well.
--
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
[jira] [Updated] (AVRO-1069) HttpTransceiver never closes its
OutputStream, hinders java reuse of HTTP connections
Posted by "Thomas Andrews (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Andrews updated AVRO-1069:
---------------------------------
Summary: HttpTransceiver never closes its OutputStream, hinders java reuse of HTTP connections (was: HttpTransceiver never closes its OutputStream)
> 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
>
> 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