Bug 62432 - Memory Leak in Statement Finalizer?
Summary: Memory Leak in Statement Finalizer?
Status: NEW
Alias: None
Product: Tomcat Modules
Classification: Unclassified
Component: jdbc-pool (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-06 14:23 UTC by riegerm
Modified: 2018-06-06 14:23 UTC (History)
0 users



Attachments
proposal for StatementFinalizer with regular cleanup of statements list (5.75 KB, text/x-csrc)
2018-06-06 14:23 UTC, riegerm
Details

Note You need to log in before you can comment on or make changes to this bug.
Description riegerm 2018-06-06 14:23:06 UTC
Created attachment 35956 [details]
proposal for StatementFinalizer with regular cleanup of statements list

The StatementFinalizer keeps a list of statements which he closes
if they're still open when the connection is closed. The list keeps
weak references to the statements, so when the statement is closed
by client code, it can be garbage collected and will not be closed
by the StatementFinalizer.

However, the StatementFinalizer keeps the references to the Statements
indirectly through instances of StatementFinalizer$StatementEntry.
These instances are not cleaned up even when the statements they refer
to have long been closed. Mostly this does not seem to be a problem when
connections are closed quickly.

But we have had long running jobs that created many Statements with
the same connection where the instances of (empty) 
StatementFinalizer$StatementEntry finally brought the VM to its knees.

The useless instances of StatementFinalizer$StatementEntry kept
around in the statement list constitute a memory leak in my opinion.

The attached proposal invokes a "cleaner" method every time before a
new statement is added to the list. This method removes empty entries
from the list.
If this linear sweep of the statements list for each addition seems
an excessive loss of performance, one could imagine "throttled" invocations
(every nth time).