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 17:12:47 GMT
On 04/04/2012 17:14, Hermes Flying wrote:
> 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?

http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Resource_Definitions


> 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?
Nope. If you are using Tomcat's connection pooling that is where the
driver has to be located.

> I mean the JDBC driver would not be unloaded with the web application, right?
Correct.

> So is this an issue?
No.

> Should I have placed the H2 driver under WEB-INF/lib? 
Not if you wanted to use Tomcat's connection pooling.

> 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
No you can't since then you can't use Tomcat's connection pooling.


> 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?

It is mostly right but misses the point that threads started by the JDBC
driver have the web application's class loader as their context class
loader when they should have the class loader used to load the JDBC
driver. That is a bug in the JDBC driver.

> Should I somehow have configured the datasource to be "associated" with my web application

> instead of a generic data source?
No.

> Why?
N/A

> Should I have shut the data source myself?
No.

How?
N/A.

If all what I describe is reasonable this seems to me like a "racing"
condition.
Nope. It is a memory leak in the JDBC driver which is why Tomcat is
reporting it. When a web application shuts down, nothing should be
retaining a reference to the web application class loader. That the JDBC
driver does, is a bug in the JDBC driver.

> How should I mediate this?
Get back to the H2 folks and provide them with a link to this thread. If
they still insist that there is no bug in their driver, either live with
the bug or find an alternative driver and/or database.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message