avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Andrews (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AVRO-1069) HttpTransceiver never closes its OutputStream
Date Fri, 20 Apr 2012 21:21:33 GMT

     [ 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

        

Mime
View raw message