You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Hermes Flying <fl...@yahoo.com> on 2012/04/04 14:05:07 UTC
Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
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:
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
Re: Discrepancy between Tomcat's connection pool and tomcat's report
on memory leaks
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
Posted by Hermes Flying <fl...@yahoo.com>.
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 <us...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Discrepancy between Tomcat's connection pool and tomcat's report
on memory leaks
Posted by Mark Thomas <ma...@apache.org>.
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
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
Posted by Hermes Flying <fl...@yahoo.com>.
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 <us...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Discrepancy between Tomcat's connection pool and tomcat's report
on memory leaks
Posted by Mark Thomas <ma...@apache.org>.
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
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
Posted by Hermes Flying <fl...@yahoo.com>.
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 <pi...@pidster.com>
To: Tomcat Users List <us...@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
Posted by Pid <pi...@pidster.com>.
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
Posted by Hermes Flying <fl...@yahoo.com>.
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 <dm...@vmware.com>
To: Tomcat Users List <us...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Discrepancy between Tomcat's connection pool and tomcat's
report on memory leaks
Posted by Daniel Mikusa <dm...@vmware.com>.
----- 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org