Hi Mark,thank you for your reply. 2 questions related your mail 1)I don't understand what you are saying here: "but as of 7.0.12 yo an set the closeMethod for a resource that should be the name of a zero atg method to call to shut down the resource". Could you please explain or send a link to a reference on what you are talking about here? 2)Concerning your comment concerning the class loaders and H2. I didn't mention that the H2 driver is under $TOMCAT_HOME/lib. Does this make a difference in the behavior you describe? I mean the JDBC driver would not be unloaded with the web application, right? So is this an issue? Should I have placed the H2 driver under WEB-INF/lib? I can do that but then from my point of view Tomcat's setup has many exception/corner cases and the setup is not "uniform" but requires some background knowledge of the implementation of Tomcat Also as mentioned to Dan: My undestanding of what is happening here is the following 1) My application uses Tomcat's connection pool from the data source 2) My application uses H2 as a file database. H2 starts back end(s) thread which is about logging (H2 logging) and possibly other tasks and that is the thread that catalina complaints about 3) H2 remains open as long as there are open connections and is closed when the last connection is released 4) My application uses Tomcat's connection pool and as a result Tomcat "decides" when the data source should be disposed or when connections are released (not my code). 5) I shutdown Tomcat. 6) The connection pool of Tomcat has still connections (e.g. idle) and so H2 does not shutdown. Hence it's lock file and related background threads are still running. 7) Tomcat shuts down my application but does not dispose off the connection pool (yet). I believe this happens because of the way Tomcat is being shut down (as sequence of actions I mean). 8) Since the connection pool has not been disposed, there are still connections and as a result H2 is still running 9) Tomcat's memory leak detection mechanism detects H2 threads started from GenericApplication which uses H2 and gives the report in catalina.out. So Tomcat gives the report first and then proceeds with the shutdown (and this perhaps is not correct? I can't say) 10) Tomcat eventually shuts down.
Is this scenario as I describe it, wrong? Should I somehow have configured the datasource to be "associated" with my web application instead of a generic data source? Why? Should I have shut the data source myself? How? If all what I describe is reasonable this seems to me like a "racing" condition. How should I mediate this? Thank you for your time ________________________________ From: Mark Thomas <ma...@apache.org> To: Tomcat Users List <users@tomcat.apache.org> Sent: Wednesday, April 4, 2012 6:42 PM Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks On 04/04/2012 13:54, Hermes Flying wrote: > Hi Pid, > > This is the configuration The following entry is in server.xml > > <Resource name="jdbc_GENERIS_RS" auth="Container" > type="javax.sql.DataSource" driverClassName="org.h2.Driver" > url="jdbc:h2:file:/opt/en/repos/tomcat/webapps/GeneralApplication/db/internaldatabase;SCHEMA=genericschema" > > username="root" password="sa" > maxActive="20" maxIdle="10" maxWait="-1" /> OK. That means it is a server wide connection pool... > And the following entry is under $TOMCAT_HOME/conf/context.xml > > <ResourceLink name="jdbc/GenericDataSource" global="jdbc_GENERIS_RS" > type="javax.sql.DataSource"/> ... that is shared by one or more applications. > Concerning your other questions: 1) Yes I could shut down the > database manually but I would like to do it as a last resort if this > issue is something that can not be fixed since I believe that my > setup is correct and should be supported as is Based on what I have seen so far, I would agree. > 2) You say that it depends if I should close down the connection > myself. But how can I do that? A javax.sql.DataSource does not > provide a close method. I would have to cast to > org.apache.tomcat.dbcp.dbcp.BasicDataSource to call close. I am not > sure if this is the proper approach. I mean I then get bind to this > class, right? Or there is another way? Not that is applies in this case (since the pool is global rather than per application) but as of 7.0.12 yo an set the closeMethod for a resource that should be the name of a zero atg method to call to shut down the resource >> SEVERE: The web application [/GeneralApplication] appears to have >> started a thread named [H2 Log Writer GENERICAPPLICATION] but has >> failed to stop it. This is very likely to create a memory leak. Apr >> 4, 2012 2:32:54 PM org.apache.catalina.loader.WebappClassLoader >> clearReferencesThreads SEVERE: The web application >> [/GeneralApplication] appears to have started a thread named [H2 >> File Lock Watchdog >> /opt/en/repos/tomcat/webapps/GeneralApplication/db/internaldatabase.lock.db] >> but has failed to stop it. This is very likely to create a memory >> leak. >> >> Why do I get these messages? What is happening is the the JDBC driver is creating threads. When a thread is created the context class loader for the thread is - by default - set to the current context class loader. These threads are being created when the current context class loader is the web application class loader. i.e. they are being created as a result of the web application using the JDBC driver (via the pool). When the web application stops those threads are still in use (since it is a global pool) but the threads retain a reference to the web application class loader and this creates a memory leak. >> Additionally the input from H2 dev is that these messages are a >> Tomcat problem. Tomcat should have first disposed of the connection >> pool and then log the running threads.Their explanation seem >> correct to me. > > That's the usual first response. Let's figure out whether it's > correct... And it is wrong. When H2 creates those threads it should ensure that the context class loader for the threads is set to the same class loader that loaded the JDBC driver. We had similar issues with the evictor thread in Apache Commons Pool (used by DBCP). Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
