Re: useCompression=true and potential Memory leak due to connection tracking via CompressionInputStreamMemoryLeak
Posted by: Dominic Tootell
Date: May 13, 2013 06:07AM

Hi Alexander,

Thank you very much for your quick reply. I've taken a look, just visually, at the patch in; and I am wondering if this will work in all cases. This could be my mis-understanding behind the use of the trackConnection method in NonRegisteringDriver and the AbandonedConnectionCleanupThread.

The fix you have for CompressionInputStream is:

public void close() throws IOException {
+ this.connection = null;;
this.buffer = null;
+ this.inflater.end();
this.inflater = null;

the addition of this.connection=null in the close.

My understanding of the use case for the trackConnection in NonRegisteringDriver, (again apologies if I'm reading this incorrectly), is that the AbandonedConnectionCleanupThread, and the NonRegisteringDriver's map of ConnectionPhantomReferences is that it catches the use cases where Client applications forget to call Connection.close(); and are accidentally just nulling the reference to the connection:

i.e. The difference between the client app doing:

connection = null


connection = null

My understanding of the ConnectionPhantomReference and the trackConnection, is that When the connection is nulled, the connection is no longer strongly referenced and is queued on the reference queue by the JVM, ready for the AbandonedConnectionCleanupThread to poll off the reference queue, and call the ".close()" on the connection object, freeing up the underlying sockets, streams etc; for those connection objects which the user forget to issue .close() on. However, the issue here is that the Connection won't be queued on the reference queue, as it is still strongly referenced because the CompressionInputStream is strongly referencing it. As a result the AbandonedConnectionCleanupThread poll never gets the PhantomReference, and can't call .close().

It is for this use case, I was thinking that a WeakReference on the Connection object in the CompressionInputStream would be more of a solution, than just nulling out the stong reference in the .close() of the CompressionInputStream

Again I'm not sure on on the places that .close() is called in the CompressionInputStream and if, by not calling ConnectionImpl's .close() that it means that the input streams close() won't occur either; and as a result the this.connection in CompressionInputStream won't be null, and the nulled out Connection object will leak.

Please let me know if that doesn't make sense.


Options: ReplyQuote

Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.