https://issues.apache.org/bugzilla/show_bug.cgi?id=54732
Bug ID: 54732
Summary: StatementCache interceptor does not forward calls to
Statement.close() which causes memory leaks
Product: Tomcat 7
Version: 7.0.34
Hardware: PC
Status: NEW
Severity: major
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: ber...@step.polymtl.ca
Classification: Unclassified
ML ref:
http://mail-archives.apache.org/mod_mbox/tomcat-users/201303.mbox/browser
When using Tomcat's jdbc-pool with the StatementCache interceptor (the default
for TomEE 1.5.1), the actual java.sql.Statement.close() method is not called on
the Statements. This causes severe memory leaks, at least with the MySQL
driver.
I see what could be a bug in StatementCache#closeInvoked() which is called by
the above method. Here is the code with my own comments added:
@Override
public void closeInvoked() {
boolean shouldClose = true;
if (cacheSize.get() < maxCacheSize) {
// omitted for brievety
}
closed = true;
// [1] I think "delegate = null" is done too soon
delegate = null;
if (shouldClose) {
// check its body below
super.closeInvoked();
}
}
// This is super.closeInvoked()
public void closeInvoked() {
if (getDelegate()!=null) {
// never true when coming from
// StatementCache#closeInvoked()
// because of [1]
try {
getDelegate().close();
}catch (SQLException ignore) {
}
}
closed = true;
delegate = null;
}
To test this, step into org.apache.tomcat.jdbc.test.TestStatementCache tests
testPreparedStatementCache and testPreparedStatementCache2. The calls to
Statement.close() are intercepted but never forwarded to the actual Statement.
Perhaps some kind of mock could be used to make sure Statement.close() is
called on each created Statement.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
