Re: useCompression=true and potential Memory leak due to connection tracking via CompressionInputStreamMemoryLeak
Hi Alexander,
Thank you very much for your quick reply. I've taken a look, just visually, at the patch in bugs.mysql.com/bug.php?id=68400; 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.in.close();
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
AND
connection.close()
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.
cheers
/dom