HttpUrlConnection not closed

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Creating a MessageQueue and calling receiveMessage on a schedule (once 
per minute, etc.)

What is the expected output? What do you see instead?
Expected - the app should keep running normally.  Instead, the memory 
keeps increasing until an OOM situation occurs and the JVM crashes.

What version of the product are you using? On what operating system?
Current CVS.  Deployed on CentOS5 under JRockitR27-3.1 and Tomcat 6.  Same 
symptoms also occured with an extension of AbstractBaseService running on 
a CentOS5/JRockitR27-3.1 EC2 instance (no Tomcat).

Please provide any additional information below.
Spent a few days tracking this one down, and once located, the fix was 
pretty easy.  In receiveMessages I simply wrapped everything the 
HttpURLConnection with a finally to disconnect it and wrapped the 
InputStream with a finally to close it.  This immediately stopped the 
memory leak.  However, there are a number of other methods which work the 
same way which (I expect) will cause similiar problems once used (with 
pooling, etc.).

While it would be a fairly dramatic change, I would suggest creating a 
control object which calls the AWSQueryConnection.makeRequest method, then 
an abstract "execute" method which could be implemented by users of the 
client, followed by the cleanup.  This inverted-control would ensure that 
the clients can use it safely without having to understand how it works 
and dealing with clean-up.  You could leave the existing makeRequest 
method for backwards compatibility with existing users, but deprecate it 
with warnings about cleanup.

Original issue reported on code.google.com by tc...@interprisesoftware.com on 4 Oct 2007 at 7:03

[GoogleCodeExporter]

Thanks for finding this! This could explain something I'm seeing on my own
application. issue #14 would involve moving to HttpClient, so that sounds like 
the
right time to address this issue. I've already started converting some code 
locally
for testing.

Original comment by dkavan...@gmail.com on 5 Oct 2007 at 11:32

• Changed state: Accepted

[GoogleCodeExporter]

With the conversion to commons-httpclient, I've also ensured the connection 
resources
are cleaned up by calling method.releaseConnection() in a finally block.

Original comment by dkavan...@gmail.com on 5 Nov 2007 at 8:34

• Changed state: Fixed