Tomcat finalizer memory leak ???

Question

I have was profiling my application using yourkit profiler. The statisxtics are stange and I need help to understand them.
Here is the scenario:
1) started Tomcat @ 1:00 profiling using yourkit profiler - only 1 context, our application. I set the profiler to take a heap snapshot on 90% of heap usage. I set the heap to 64Megs because I knew there would be only 2 users on it, and I wanted to get to a point of OOME faster
2) took a snapshot before anyone logged in, and after Tomcat booted up
3) took a few other snapshots in the first hour of usage while 2 people using system
4) everyone left ~ 5:00pm and logged out of our system. The only thing running was Tomcat
5) @ ~ 2:00am the next morning, a snapshot was taken because 90% of the heap was in use (???)
6) the next morning, all the heap was used and Tomcat would only respond with OOME - java.lang.heap out of memory error
I compared the last heap snapshot I took during step 3 above and the low memory snapshot and found that 73% of memory was being held by
java.lang.ref.Finalizer. WHAT THE HECK IS THAT? I have looked all over the web and have found no information on what it is or what it does?
The closest I have come to any information is articles about java finalizers vs. destructors, and what java.lang.Object.Finalize method. I also saw a reference to the java.lang.ref.Finalizer api, but there are no javadocs describing its functinoliaty. My questions are:
1) How are Finalizer and java.lang.Object.Finalize related - or are they? what is java.lang.ref.Finalizer and what do they do?
2) WHY would I have over 200000 Finalizer objects occupying 73% of the heap at step 5 (see above), when in my final snapshot of step 3 I had 0???
3) we are also using org.apache.commons.dbcp and the sql server JTDS driver for our db connection pool in the following manner. Does anyone know if there is a problem with this?
DriverAdapterCPDS cpds = new DriverAdapterCPDS();
try
cpds.setUrl( databaseURL );
cpds.setUser( user );
cpds.setPassword( password );
cpds.setDriver( databaseDriver );
SharedPoolDataSource tds = new SharedPoolDataSource();
tds.setConnectionPoolDataSource( cpds );
tds.setMaxActive( iMaxActive ); // Connection pool Size
tds.setMaxWait( iMaxWait ); // Max connection wait time (in miliseconds)
ds = tds;
catch( Exception e )
e.printStackTrace();
I will be repeating this test today, but will take heap snapshots on an hourly interval - HOPEFULLY, I can find what is going on
Is there any one out there who can help us find this memory leak? Fee for Service could be acceptable?
John McClain
Senior Software Engineer
TCS Healthcare
[email protected]
[phone]x235
"Skepticism is the first step toward truth"

Answer 1

I did find some information on sourceforge about jTDS having memory issues with PreparedStatements (v1.2) or queries using scrollable cursors (v1.1). The scrollable cursor issue seems to be the closes match to your problem so if you are using version 1.1 you may want to move up to version 1.2. Also check your SQL statements to see if you are using scrollable cursors and if they can be changed to read only.