tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
Date Wed, 04 Apr 2012 15:42:23 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message