Hi Mark,
I think the problem is in com.mysql.jdbc.profiler.ProfileEventSink where
the map CONNECTIONS_TO_SINKS is filled but elements are never removed.
How about this patch with which the Connections are garbage collected in
my test case:
1. add
public static synchronized void removeInstance(Connection conn)
{
CONNECTIONS_TO_SINKS.remove(conn);
}
to ProfileEventSink
2. add
ProfileEventSink.removeInstance(this);
to the finally block in Connection.realClose
Best regards
Achim
Hi Mark,
Mark Matthews wrote:
Achim,
Adding "profileSQL=true" to your URL causes the driver to log _every_
query to System.err, or another defined logger, so depending on how your
logging is setup, that could be filling a lot of memory due to how your
logging system buffers things.
I am using log4j and the MySQL driver seems to log automatically to the
log4j logger "MySQL" in this case.
The problem occurs even if I set the loglevel for this logger to ERROR,
so nothing is logged.
But the fact remains that the number of com.mysql.jdbc.Connection
objects in the heap is increasing.
It is not the logging system that takes the memory.
BTW: I thought the problem would occur with any property setting in the
JDBC url but it seems to arise only with "profileSQL".
"profileSQL" is not designed to be used in a production setting, is
there a reason you're running it in this manner?
No. I will remove it.
5 messages in com.mysql.lists.javaRe: Memory leak with c3p0 using Conne...
.java