| Bug #13204 | Memory Leak in 3.1.10 | ||
|---|---|---|---|
| Submitted: | 14 Sep 2005 23:05 | Modified: | 15 Sep 2005 14:26 |
| Reporter: | Prishant Mantrao | ||
| Status: | Can't repeat | ||
| Category: | Connector/J | Severity: | S2 (Serious) |
| Version: | 3.1.10 | OS: | Microsoft Windows (Windows XP) |
| Assigned to: | Target Version: | ||
[14 Sep 2005 23:05]
Prishant Mantrao
[15 Sep 2005 14:26]
Mark Matthews
There are no known memory leaks in Connector/J 3.1.10. We have quite a few users using it in production in heavy-load deployments as well, so we'd hear about memory leaks right away. One difference between Connector/J 3.0 and 3.1 is that 3.1 is much pickier about requiring applications to call .close() on all resources they use (statements, result sets), because it's required by the JDBC specification. Please ensure that all code paths in your application call .close() on the statements and result sets it creates. (This can _appear_ to be a memory leak, since resources are not getting released until the connection is finally closed, which in a connection pooling environment might not happen for quite a while).
[15 Sep 2005 18:27]
Mark Matthews
We can't diagnose this based on the information you've given. I'm not saying that C/J isn't at fault here, but we've got a lot of people using it in the field without any memory leaks. Unless you have a backtrace of object allocations, or output from a memory profiler, there's not a lot we can do here to help you, unfortunately, especially given that your app is running inside Tomcat, which has been known to have memory leaks from time-to-time, so the problem is not isolated. If you can extract your example into a _standalone_ Java program, and it still has memory leaks, then we might be able to reproduce it here.
[15 Sep 2005 18:40]
Mark Matthews
Can you attach your profiler's report, maybe it can give us some insight?
[15 Sep 2005 21:06]
Mark Matthews
Are you saying the application in the JVM leaks memory, or the MySQL _server_ (that's two different things). If the _server_ leaks memory, what does adding "useServerPrepStmts=false" do to the situation?
[15 Sep 2005 22:08]
Mark Matthews
If dontTrackOpenResources=true is enabled and your problem goes away, then it means _your_ application (or something it depends on, such as DBCP) is leaking statements or result sets. If you enable "useUsageAdvisor=true", the driver will log where in your application results and statements were created that were never closed once the connection closes (as long as you haven't enabled "dontTrackOpenResources", that is).
[21 Sep 2005 11:45]
Christian Franzel
It might by related to a different behaviour in ResultSet::getStatement(). In the older
version (at least in 2.0 the following code would release all the ressources:
try {
resultSet.close();
} finally {
Statement stmt = resultSet.getStatement();
if (stmt != null) {
stmt.close();
}
}
In the 3.1.10 version (don't know when that changed) the resultSet will return null after
it has been closed, so the code above now lets the statement dangling. As there is no
explicit specification on the method to return null after invoking close I consider this
as a bug but that may be arguable. Anyway... first obtaining the reference to the
statement and then closing resultSet and statement will work and maybe that is the cause
of the troubles in the described case.
