Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
On 04/04/2012 21:59, Hermes Flying wrote: Thank you for your explanation. I will take this to H2 but I have one more question on your comment: 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. My question is: is this leak a general problem that should concern me or something that is an issue only on application undeployment? You will get a memory leak when the application is stopped for any reason. If this happens at Tomcat shut down it isn't that much of an issue. At any other point it is a problem. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
On 04/04/2012 16:53, Hermes Flying wrote:
Which is indicating that the application deployed to /GeneralApplication
is creating a thread named H2 Log Writer GENERICAPPLICATION and never
stopping it. I do not believe that this would be associated with the pool
created by Tomcat as that would be created as a global resource available
to all applications and not specific to /GeneralApplication.
I can't really say a whole lot more about what is going on, just that this
strikes me as odd. If it were my app, I'd dig into this more and see what
is creating that thread. Possibly with a profiler or thread dumps.
What is happening here (as I undestand it 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?
If you define the DataSource in GlobalNamingResources the pool will be
started and stopped with the Tomcat lifecycle.
Applications have their own lifecycle inside Tomcat, they are started
after Tomcat (obviously) and stopped before Tomcat stops (also obviously).
This is why the pool will not stop before your application, unless you
do something manual to change that.
If an application causes a thread to come into existence and allowing it
to have the WebappClassLoader as its context classloader value, but does
not shut it down, Tomcat complains.
Should I somehow have configured the datasource to be associated with my
web application instead of a generic data source?
Maybe, you could test configuring the pool Resource in the Context,
where the ResourceLink currently is.
Why?
So it doesn't cause a leak?
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?
Maybe the H2 devs will fix the classloader problem.
p
Thank you for your time.
From: Daniel Mikusa dmik...@vmware.com
To: Hermes Flying flyingher...@yahoo.com
Sent: Wednesday, April 4, 2012 5:14 PM
Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report
on memory leaks
- Original Message -
What I do is get the dataSource inside a ServletContextListener and
save it in servlet context (as part of a DAO Factory):
public void contextInitialized(ServletContextEvent sce) {
ServletContext context = sce.getServletContext();
DataSource dataSource = null;
try {
dataSource = (DataSource) new
InitialContext().lookup(java:/comp/env/jdbc/GenericDataSource);
context.setAttribute(daogenericfactory,
DAOGenericFactory.getInstance(dataSource));
} catch (NamingException e) {
e.printStackTrace();
}
}
The DAOGenericFactory just returns specific DAO objects passing in
their constructor the data source.
Each DAO instance has an member variable of DataSource and for action
to the database I do in order to get a connection:
public Connection getConnection() throws Exception{
return dataSource.getConnection();
}
So I use the Connection this way and I always close the connections
in order to be returned back to the pool.
The only thing perhaps to mention is that I create new DAO objects
passing this data source (I don't reuse instances of DAO).
So I don't have a pool of my own. I just use DAO pattern .
This is happening in my web application GeneralApplication
Is this information adequate/clear?
Definitely clear. It just doesn't seem to match up with the output from the
log files. You're seeing
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
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
On 1:59 PM, Pid wrote: If you define the DataSource in GlobalNamingResources the pool will be started and stopped with the Tomcat lifecycle. Applications have their own lifecycle inside Tomcat, they are started after Tomcat (obviously) and stopped before Tomcat stops (also obviously). This is why the pool will not stop before your application, unless you do something manual to change that. If an application causes a thread to come into existence and allowing it to have the WebappClassLoader as its context classloader value, but does not shut it down, Tomcat complains. This is similar to the problem with JDBC 4.0 drivers. The API docs state: Existing programs which currently load JDBC drivers using Class.forName() will continue to work without modification. However, if you continue reading and read closely, it becomes apparent that drivers are automatically registered with DriverManager when a database connection is created. In essence, a reference to a driver is implicitly created and it is the responsibility of the application to remove the reference. This doesn't seem like good design to me but no fault to Tomcat. -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
On 1:59 PM, Terence M. Bandoian wrote: On 1:59 PM, Pid wrote: If you define the DataSource in GlobalNamingResources the pool will be started and stopped with the Tomcat lifecycle. Applications have their own lifecycle inside Tomcat, they are started after Tomcat (obviously) and stopped before Tomcat stops (also obviously). This is why the pool will not stop before your application, unless you do something manual to change that. If an application causes a thread to come into existence and allowing it to have the WebappClassLoader as its context classloader value, but does not shut it down, Tomcat complains. This is similar to the problem with JDBC 4.0 drivers. The API docs state: Existing programs which currently load JDBC drivers using Class.forName() will continue to work without modification. However, if you continue reading and read closely, it becomes apparent that drivers are automatically registered with DriverManager when a database connection is created. In essence, a reference to a driver is implicitly created and it is the responsibility of the application to remove the reference. This doesn't seem like good design to me but no fault to Tomcat. -Terence Bandoian Correction. Drivers automatically register themselves with DriverManager when the driver class is loaded. -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
- Original Message - Hi, I am using Tomcat 7.0.25 in a Linux machine I am using Tomcat's connection pool (org.apache.tomcat.dbcp.dbcp.BasicDataSource). As database I am using H2 as a file database. Where are you defining the connection pool? Can you include your configuration? Dan All is ok, but I have the following problem. On shutdown of Tomcat I see in catalina.out: 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? As I understand these messages, H2 is still running on shutdown and the documentation they have says that the database will shutdown once the last connection is closed (and the connections are handled by the pool i.e. Tomcat) 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. Is this a known issue? Why do I see these errors in catalina? Should I somehow dispose off the connection pool myself? Thank you for your time Best Regards, FH - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
On 04/04/2012 13:05, Hermes Flying wrote: Hi, I am using Tomcat 7.0.25 in a Linux machine I am using Tomcat's connection pool (org.apache.tomcat.dbcp.dbcp.BasicDataSource). As database I am using H2 as a file database. All is ok, but I have the following problem. On shutdown of Tomcat I see in catalina.out: In which file have you defined the pool? 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? When the application shuts down Tomcat tries to detect prevent memory leaks by examining threads various things associated with the WebappClassloader. As I understand these messages, H2 is still running on shutdown and the documentation they have says that the database will shutdown once the last connection is closed (and the connections are handled by the pool i.e. Tomcat) So there is no way to manually the database down? 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... Is this a known issue? Not that I've come across here. Why do I see these errors in catalina? As above. Should I somehow dispose off the connection pool myself? Depends. p Thank you for your time Best Regards, FH -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
Hi Dan, 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 / And the following entry is under $TOMCAT_HOME/conf/context.xml ResourceLink name=jdbc/GenericDataSource global=jdbc_GENERIS_RS type=javax.sql.DataSource/ Do you need more details than these? From: Daniel Mikusa dmik...@vmware.com To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 4, 2012 3:35 PM Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks - Original Message - Hi, I am using Tomcat 7.0.25 in a Linux machine I am using Tomcat's connection pool (org.apache.tomcat.dbcp.dbcp.BasicDataSource). As database I am using H2 as a file database. Where are you defining the connection pool? Can you include your configuration? Dan All is ok, but I have the following problem. On shutdown of Tomcat I see in catalina.out: 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? As I understand these messages, H2 is still running on shutdown and the documentation they have says that the database will shutdown once the last connection is closed (and the connections are handled by the pool i.e. Tomcat) 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. Is this a known issue? Why do I see these errors in catalina? Should I somehow dispose off the connection pool myself? Thank you for your time Best Regards, FH - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
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 / And the following entry is under $TOMCAT_HOME/conf/context.xml ResourceLink name=jdbc/GenericDataSource global=jdbc_GENERIS_RS type=javax.sql.DataSource/ 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 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? Thank you From: Pid p...@pidster.com To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 4, 2012 3:43 PM Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks On 04/04/2012 13:05, Hermes Flying wrote: Hi, I am using Tomcat 7.0.25 in a Linux machine I am using Tomcat's connection pool (org.apache.tomcat.dbcp.dbcp.BasicDataSource). As database I am using H2 as a file database. All is ok, but I have the following problem. On shutdown of Tomcat I see in catalina.out: In which file have you defined the pool? 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? When the application shuts down Tomcat tries to detect prevent memory leaks by examining threads various things associated with the WebappClassloader. As I understand these messages, H2 is still running on shutdown and the documentation they have says that the database will shutdown once the last connection is closed (and the connections are handled by the pool i.e. Tomcat) So there is no way to manually the database down? 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... Is this a known issue? Not that I've come across here. Why do I see these errors in catalina? As above. Should I somehow dispose off the connection pool myself? Depends. p Thank you for your time Best Regards, FH -- [key:62590808]
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
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
Which is indicating that the application deployed to /GeneralApplication is
creating a thread named H2 Log Writer GENERICAPPLICATION and never
stopping it. I do not believe that this would be associated with the pool
created by Tomcat as that would be created as a global resource available
to all applications and not specific to /GeneralApplication.
I can't really say a whole lot more about what is going on, just that this
strikes me as odd. If it were my app, I'd dig into this more and see what is
creating that thread. Possibly with a profiler or thread dumps.
What is happening here (as I undestand it 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: Daniel Mikusa dmik...@vmware.com
To: Hermes Flying flyingher...@yahoo.com
Sent: Wednesday, April 4, 2012 5:14 PM
Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report
on memory leaks
- Original Message -
What I do is get the dataSource inside a ServletContextListener and
save it in servlet context (as part of a DAO Factory):
public void contextInitialized(ServletContextEvent sce) {
ServletContext context = sce.getServletContext();
DataSource dataSource = null;
try {
dataSource = (DataSource) new
InitialContext().lookup(java:/comp/env/jdbc/GenericDataSource);
context.setAttribute(daogenericfactory,
DAOGenericFactory.getInstance(dataSource));
} catch (NamingException e) {
e.printStackTrace();
}
}
The DAOGenericFactory just returns specific DAO objects passing in
their constructor the data source.
Each DAO instance has an member variable of DataSource and for action
to the database I do in order to get a connection:
public Connection getConnection() throws Exception{
return dataSource.getConnection();
}
So I use the Connection this way and I always close the connections
in order to be returned back to the pool.
The only thing perhaps to mention is that I create new DAO objects
passing this data source (I don't reuse instances of DAO).
So I don't have a pool of my own. I just use DAO pattern .
This is happening in my web application GeneralApplication
Is this information adequate/clear?
Definitely clear. It just doesn't seem to match up with the output from the
log files. You're seeing
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.
Which is indicating that the application deployed to /GeneralApplication is
creating a thread named H2 Log Writer GENERICAPPLICATION and never stopping
it. I do not believe that this would be associated with the pool created by
Tomcat as that would be created as a global resource available to all
applications and not specific to /GeneralApplication.
I can't really say a whole lot more about what is going on, just that this
strikes me as odd. If it were my app, I'd dig into this more and see what is
creating that thread. Possibly with a profiler or thread dumps.
Also how did you test it?
I took a stock Tomcat 7 instance, added the Resource/ tag you specified to
server.xml and added the ResourceLink/ tag you specified to context.xml. I
then deployed a test app that I have, it's a simple
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
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
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
just set minIdle=0 and enable the eviction process to take care of it.
Filip
- Original Message -
From: Hermes Flying flyingher...@yahoo.com
To: Daniel Mikusa dmik...@vmware.com
Cc: users@tomcat.apache.org
Sent: Wednesday, April 4, 2012 9:53:30 AM
Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report
on memory leaks
Which is indicating that the application deployed to
/GeneralApplication is creating a thread named H2 Log Writer
GENERICAPPLICATION and never stopping it. I do not believe
that this would be associated with the pool created by Tomcat as
that would be created as a global resource available to all
applications and not specific to /GeneralApplication.
I can't really say a whole lot more about what is going on, just
that this strikes me as odd. If it were my app, I'd dig into this
more and see what is creating that thread. Possibly with a
profiler or thread dumps.
What is happening here (as I undestand it 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: Daniel Mikusa dmik...@vmware.com
To: Hermes Flying flyingher...@yahoo.com
Sent: Wednesday, April 4, 2012 5:14 PM
Subject: Re: Discrepancy between Tomcat's connection pool and
tomcat's report on memory leaks
- Original Message -
What I do is get the dataSource inside a ServletContextListener and
save it in servlet context (as part of a DAO Factory):
public void contextInitialized(ServletContextEvent sce) {
ServletContext context = sce.getServletContext();
DataSource dataSource = null;
try {
dataSource = (DataSource) new
InitialContext().lookup(java:/comp/env/jdbc/GenericDataSource);
context.setAttribute(daogenericfactory,
DAOGenericFactory.getInstance(dataSource));
} catch (NamingException e) {
e.printStackTrace();
}
}
The DAOGenericFactory just returns specific DAO objects passing in
their constructor the data source.
Each DAO instance has an member variable of DataSource and for
action
to the database I do in order to get a connection:
public Connection getConnection() throws Exception{
return dataSource.getConnection();
}
So I use the Connection this way and I always close the connections
in order to be returned back to the pool.
The only thing perhaps to mention is that I create new DAO objects
passing this data source (I don't reuse instances of DAO).
So I don't have a pool of my own. I just use DAO pattern .
This is happening in my web application GeneralApplication
Is this information adequate/clear?
Definitely clear. It just doesn't seem to match up with the output
from the log files. You're seeing
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.
Which is indicating that the application deployed to
/GeneralApplication is creating a thread named H2 Log Writer
GENERICAPPLICATION and never stopping it. I do not believe that
this would be associated with the pool created by Tomcat as that
would be created as a global resource available to all applications
and not specific to /GeneralApplication.
I can't really say a whole lot
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
But if I set 'minIdle=0' all the connections would close imediatelly, right?
So why would I need a connection pool in the first place if I do this?
From: Filip Hanik Mailing Lists devli...@hanik.com
To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, April 4, 2012 7:28 PM
Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report
on memory leaks
just set minIdle=0 and enable the eviction process to take care of it.
Filip
- Original Message -
From: Hermes Flying flyingher...@yahoo.com
To: Daniel Mikusa dmik...@vmware.com
Cc: users@tomcat.apache.org
Sent: Wednesday, April 4, 2012 9:53:30 AM
Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report
on memory leaks
Which is indicating that the application deployed to
/GeneralApplication is creating a thread named H2 Log Writer
GENERICAPPLICATION and never stopping it. I do not believe
that this would be associated with the pool created by Tomcat as
that would be created as a global resource available to all
applications and not specific to /GeneralApplication.
I can't really say a whole lot more about what is going on, just
that this strikes me as odd. If it were my app, I'd dig into this
more and see what is creating that thread. Possibly with a
profiler or thread dumps.
What is happening here (as I undestand it 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: Daniel Mikusa dmik...@vmware.com
To: Hermes Flying flyingher...@yahoo.com
Sent: Wednesday, April 4, 2012 5:14 PM
Subject: Re: Discrepancy between Tomcat's connection pool and
tomcat's report on memory leaks
- Original Message -
What I do is get the dataSource inside a ServletContextListener and
save it in servlet context (as part of a DAO Factory):
public void contextInitialized(ServletContextEvent sce) {
ServletContext context = sce.getServletContext();
DataSource dataSource = null;
try {
dataSource = (DataSource) new
InitialContext().lookup(java:/comp/env/jdbc/GenericDataSource);
context.setAttribute(daogenericfactory,
DAOGenericFactory.getInstance(dataSource));
} catch (NamingException e) {
e.printStackTrace();
}
}
The DAOGenericFactory just returns specific DAO objects passing in
their constructor the data source.
Each DAO instance has an member variable of DataSource and for
action
to the database I do in order to get a connection:
public Connection getConnection() throws Exception{
return dataSource.getConnection();
}
So I use the Connection this way and I always close the connections
in order to be returned back to the pool.
The only thing perhaps to mention is that I create new DAO objects
passing this data source (I don't reuse instances of DAO).
So I don't have a pool of my own. I just use DAO pattern .
This is happening in my web application GeneralApplication
Is this information adequate/clear?
Definitely clear. It just doesn't seem to match up with the output
from the log files. You're seeing
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
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
no, that would happen if you set maxIdle=0, not minIdle
- Original Message -
From: Hermes Flying flyingher...@yahoo.com
To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, April 4, 2012 10:45:24 AM
Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report
on memory leaks
But if I set 'minIdle=0' all the connections would close imediatelly,
right?
So why would I need a connection pool in the first place if I do
this?
From: Filip Hanik Mailing Lists devli...@hanik.com
To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, April 4, 2012 7:28 PM
Subject: Re: Discrepancy between Tomcat's connection pool and
tomcat's report on memory leaks
just set minIdle=0 and enable the eviction process to take care of
it.
Filip
- Original Message -
From: Hermes Flying flyingher...@yahoo.com
To: Daniel Mikusa dmik...@vmware.com
Cc: users@tomcat.apache.org
Sent: Wednesday, April 4, 2012 9:53:30 AM
Subject: Re: Discrepancy between Tomcat's connection pool and
tomcat's report on memory leaks
Which is indicating that the application deployed to
/GeneralApplication is creating a thread named H2 Log Writer
GENERICAPPLICATION and never stopping it. I do not believe
that this would be associated with the pool created by Tomcat as
that would be created as a global resource available to all
applications and not specific to /GeneralApplication.
I can't really say a whole lot more about what is going on, just
that this strikes me as odd. If it were my app, I'd dig into
this
more and see what is creating that thread. Possibly with a
profiler or thread dumps.
What is happening here (as I undestand it 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: Daniel Mikusa dmik...@vmware.com
To: Hermes Flying flyingher...@yahoo.com
Sent: Wednesday, April 4, 2012 5:14 PM
Subject: Re: Discrepancy between Tomcat's connection pool and
tomcat's report on memory leaks
- Original Message -
What I do is get the dataSource inside a ServletContextListener
and
save it in servlet context (as part of a DAO Factory):
public void contextInitialized(ServletContextEvent sce) {
ServletContext context = sce.getServletContext();
DataSource dataSource = null;
try {
dataSource = (DataSource) new
InitialContext().lookup(java:/comp/env/jdbc/GenericDataSource);
context.setAttribute(daogenericfactory,
DAOGenericFactory.getInstance(dataSource));
} catch (NamingException e) {
e.printStackTrace();
}
}
The DAOGenericFactory just returns specific DAO objects passing
in
their constructor the data source.
Each DAO instance has an member variable of DataSource and for
action
to the database I do in order to get a connection:
public Connection getConnection() throws Exception{
return dataSource.getConnection();
}
So I use the Connection this way and I always close the
connections
in order to be returned back to the pool.
The only thing perhaps to mention is that I create new DAO
objects
passing this data source (I don't reuse instances of DAO).
So I
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
Ok. So how is the configuration parameter fixing my problem? Would you please
explain this to me to undestand how this works?
From: Filip Hanik Mailing Lists devli...@hanik.com
To: Tomcat Users List users@tomcat.apache.org; Hermes Flying
flyingher...@yahoo.com
Sent: Wednesday, April 4, 2012 7:50 PM
Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report
on memory leaks
no, that would happen if you set maxIdle=0, not minIdle
- Original Message -
From: Hermes Flying flyingher...@yahoo.com
To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, April 4, 2012 10:45:24 AM
Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report
on memory leaks
But if I set 'minIdle=0' all the connections would close imediatelly,
right?
So why would I need a connection pool in the first place if I do
this?
From: Filip Hanik Mailing Lists devli...@hanik.com
To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, April 4, 2012 7:28 PM
Subject: Re: Discrepancy between Tomcat's connection pool and
tomcat's report on memory leaks
just set minIdle=0 and enable the eviction process to take care of
it.
Filip
- Original Message -
From: Hermes Flying flyingher...@yahoo.com
To: Daniel Mikusa dmik...@vmware.com
Cc: users@tomcat.apache.org
Sent: Wednesday, April 4, 2012 9:53:30 AM
Subject: Re: Discrepancy between Tomcat's connection pool and
tomcat's report on memory leaks
Which is indicating that the application deployed to
/GeneralApplication is creating a thread named H2 Log Writer
GENERICAPPLICATION and never stopping it. I do not believe
that this would be associated with the pool created by Tomcat as
that would be created as a global resource available to all
applications and not specific to /GeneralApplication.
I can't really say a whole lot more about what is going on, just
that this strikes me as odd. If it were my app, I'd dig into
this
more and see what is creating that thread. Possibly with a
profiler or thread dumps.
What is happening here (as I undestand it 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: Daniel Mikusa dmik...@vmware.com
To: Hermes Flying flyingher...@yahoo.com
Sent: Wednesday, April 4, 2012 5:14 PM
Subject: Re: Discrepancy between Tomcat's connection pool and
tomcat's report on memory leaks
- Original Message -
What I do is get the dataSource inside a ServletContextListener
and
save it in servlet context (as part of a DAO Factory):
public void contextInitialized(ServletContextEvent sce) {
ServletContext context = sce.getServletContext();
DataSource dataSource = null;
try {
dataSource = (DataSource) new
InitialContext().lookup(java:/comp/env/jdbc/GenericDataSource);
context.setAttribute(daogenericfactory,
DAOGenericFactory.getInstance(dataSource));
} catch (NamingException e) {
e.printStackTrace();
}
}
The DAOGenericFactory just returns specific DAO objects passing
in
their constructor the data source.
Each DAO instance has an member variable of DataSource
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
The real fix to your problem should have been Resource type=javax.sql.DataSource closeMethod=close .../ (available in Tomcat 7) If I understand the problem you're having is two fold 1. you see reports about memory leaks started a thread named [H2 File Lock Watchdog you should be able to fix this by setting initialSize0 so that the thread is started using the main class loader when tomcat starts, not when an app starts using the pool. (Tomcat 7's jdbc-pool does this automatically from 7.0.27 onwards, regardless of configuration) 2. The connection pool is not closed properly, again, this is addressed in the top of this email. letting the pool eventually shrink to 0, is merely a work around, but I realize it will NOT work. H2 is starting it's own thread, there is no way around this, unless there is way to shut down this thread. Maybe this shuts down if all connections are closed. Filip - Original Message - From: Hermes Flying flyingher...@yahoo.com To: Filip Hanik Mailing Lists devli...@hanik.com, Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 4, 2012 10:56:10 AM Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks Ok. So how is the configuration parameter fixing my problem? Would you please explain this to me to undestand how this works? From: Filip Hanik Mailing Lists devli...@hanik.com To: Tomcat Users List users@tomcat.apache.org; Hermes Flying flyingher...@yahoo.com Sent: Wednesday, April 4, 2012 7:50 PM Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks no, that would happen if you set maxIdle=0, not minIdle - Original Message - From: Hermes Flying flyingher...@yahoo.com To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 4, 2012 10:45:24 AM Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks But if I set 'minIdle=0' all the connections would close imediatelly, right? So why would I need a connection pool in the first place if I do this? From: Filip Hanik Mailing Lists devli...@hanik.com To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 4, 2012 7:28 PM Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks just set minIdle=0 and enable the eviction process to take care of it. Filip - Original Message - From: Hermes Flying flyingher...@yahoo.com To: Daniel Mikusa dmik...@vmware.com Cc: users@tomcat.apache.org Sent: Wednesday, April 4, 2012 9:53:30 AM Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks Which is indicating that the application deployed to /GeneralApplication is creating a thread named H2 Log Writer GENERICAPPLICATION and never stopping it. I do not believe that this would be associated with the pool created by Tomcat as that would be created as a global resource available to all applications and not specific to /GeneralApplication. I can't really say a whole lot more about what is going on, just that this strikes me as odd. If it were my app, I'd dig into this more and see what is creating that thread. Possibly with a profiler or thread dumps. What is happening here (as I undestand it 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
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
Thank you for your explanation. I will take this to H2 but I have one more question on your comment: 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. My question is: is this leak a general problem that should concern me or something that is an issue only on application undeployment? From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 4, 2012 8:12 PM Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
Hi, I am not sure how Resource type=javax.sql.DataSource closeMethod=close .../ helps (I am using Tomcat 7) Also: you should be able to fix this by setting initialSize0 so that the thread is started using the main class loader when tomcat starts, not when an app starts using the pool But how was I supposed to know this? I will try it and let you know From: Filip Hanik Mailing Lists devli...@hanik.com To: Cc: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 4, 2012 8:03 PM Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks The real fix to your problem should have been Resource type=javax.sql.DataSource closeMethod=close .../ (available in Tomcat 7) If I understand the problem you're having is two fold 1. you see reports about memory leaks started a thread named [H2 File Lock Watchdog you should be able to fix this by setting initialSize0 so that the thread is started using the main class loader when tomcat starts, not when an app starts using the pool. (Tomcat 7's jdbc-pool does this automatically from 7.0.27 onwards, regardless of configuration) 2. The connection pool is not closed properly, again, this is addressed in the top of this email. letting the pool eventually shrink to 0, is merely a work around, but I realize it will NOT work. H2 is starting it's own thread, there is no way around this, unless there is way to shut down this thread. Maybe this shuts down if all connections are closed. Filip - Original Message - From: Hermes Flying flyingher...@yahoo.com To: Filip Hanik Mailing Lists devli...@hanik.com, Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 4, 2012 10:56:10 AM Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks Ok. So how is the configuration parameter fixing my problem? Would you please explain this to me to undestand how this works? From: Filip Hanik Mailing Lists devli...@hanik.com To: Tomcat Users List users@tomcat.apache.org; Hermes Flying flyingher...@yahoo.com Sent: Wednesday, April 4, 2012 7:50 PM Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks no, that would happen if you set maxIdle=0, not minIdle - Original Message - From: Hermes Flying flyingher...@yahoo.com To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 4, 2012 10:45:24 AM Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks But if I set 'minIdle=0' all the connections would close imediatelly, right? So why would I need a connection pool in the first place if I do this? From: Filip Hanik Mailing Lists devli...@hanik.com To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 4, 2012 7:28 PM Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks just set minIdle=0 and enable the eviction process to take care of it. Filip - Original Message - From: Hermes Flying flyingher...@yahoo.com To: Daniel Mikusa dmik...@vmware.com Cc: users@tomcat.apache.org Sent: Wednesday, April 4, 2012 9:53:30 AM Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks Which is indicating that the application deployed to /GeneralApplication is creating a thread named H2 Log Writer GENERICAPPLICATION and never stopping it. I do not believe that this would be associated with the pool created by Tomcat as that would be created as a global resource available to all applications and not specific to /GeneralApplication. I can't really say a whole lot more about what is going on, just that this strikes me as odd. If it were my app, I'd dig into this more and see what is creating that thread. Possibly with a profiler or thread dumps. What is happening here (as I undestand it 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
