subject:"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

2012-04-04 Thread Daniel Mikusa



- 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

2012-04-04 Thread Pid

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

2012-04-04 Thread Mark Thomas

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

2012-04-04 Thread Filip Hanik Mailing Lists

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

2012-04-04 Thread Filip Hanik Mailing Lists

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

2012-04-04 Thread Filip Hanik Mailing Lists

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

2012-04-04 Thread Mark Thomas

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

live redeploys and memory leaks

2011-12-30 Thread S Ahmed

If I have a running application, and I redeploy, is it possible to keep the
server live or does it have to shut-down and re-load?  Any gotchas with
doing this on a busy server?

Also, I have been reading that if you don't probably clean things up in a
web app, there is a strong possibility that the class loader will not be
destroyed when re-deploying and result in OOM errors potentially (if you
redeploy frequently etc.)  How can you avoid this situation?   Is the full
proof method to start/stop the tomcat service?

Re: live redeploys and memory leaks

2011-12-30 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ahmed,

On 12/30/11 12:41 PM, S Ahmed wrote:
 If I have a running application, and I redeploy, is it possible to
 keep the server live or does it have to shut-down and re-load?  Any
 gotchas with doing this on a busy server?

If you just re-deploy, there will be a short interval where your
clients may get 404, 400, or other errors. If you use Tomcat's
parallel deployment feature, you can deploy a /second/ (or even third,
etc.) copy of your webapp: old sessions will go to the old version and
new sessions will go to the new one. Once the old sessions are all
dead, you can undeploy the old copy.

Just make sure your two versions are compatible with each other in
certain areas, such as database schema :)

 Also, I have been reading that if you don't probably clean things
 up in a web app, there is a strong possibility that the class
 loader will not be destroyed when re-deploying and result in OOM
 errors potentially (if you redeploy frequently etc.)

True.

 How can you avoid this situation?

Fix your webapp to properly clean things up. Tomcat includes some
features to avoid problems with JRE classes not behaving correctly.
See the JreMemoryLeakPreventionListener documentation for more
information.

 Is the [foolproof] method to start/stop the tomcat service?

That's what we do, but in an ideal world, you should be able to
re-deploy as much as you want.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk79++AACgkQ9CaO5/Lv0PAy+gCeK+18DDZ/9z8sAkZ8wGbv02/g
MhoAn3lOD2dK6qKe56JVCLCsxa5iKmbt
=FDDS
-END PGP SIGNATURE-

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

Issues with Memory Leaks on Tomcat 6.0.28

2010-09-23 Thread Kevin Mai

I'm getting this error on my tomcat installation: 

SEVERE: Error listenerStart 
Sep 23, 2010 2:29:40 PM org.apache.catalina.core.StandardContext start 
SEVERE: Context [/Simon] startup failed due to previous errors 
Sep 23, 2010 2:29:40 PM org.apache.catalina.loader.WebappClassLoader 
clearThreadLocalMap 
SEVERE: The web application [/Simon] created a ThreadLocal with key of type 
[java.lang.ThreadLocal] (value [java.lang.threadlo...@7befc208]) and a value of 
type [com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl] (value 
[com.ibatis.sqlmap.engine.impl.sqlmapsessioni...@39abdac9]) but failed to 
remove it when the web application was stopped. This is very likely to create a 
memory leak. 


I've already disabled IPv6 entirely and set the default settings: 

# Run Tomcat as this user ID. Not setting this or leaving it blank will use the 
# default of tomcat6. 
#TOMCAT6_USER=tomcat6 

# Run Tomcat as this group ID. Not setting this or leaving it blank will use 
# the default of tomcat6. 
#TOMCAT6_GROUP=tomcat6 

# The home directory of the Java development kit (JDK). You need at least 
# JDK version 1.5. If JAVA_HOME is not set, some common directories for 
# OpenJDK, the Sun JDK, and various J2SE 1.5 versions are tried. 
#JAVA_HOME=/usr/lib/jvm/openjdk-6-jdk 
# sun-jdk 
JAVA_HOME=/usr/lib/jvm/java-6-sun 

# Directory where the Tomcat 6 binary distribution resides. This a read-only 
# directory that can be shared by all Tomcat instances running on the machine. 
# Default: /usr/share/tomcat6 
#CATALINA_HOME=/usr/share/$NAME 

# Directory for per-instance configuration files and webapps. It contains the 
# directories conf, logs, webapps, work and temp. See RUNNING.txt for details. 
# Default: /var/lib/tomcat6 
#CATALINA_BASE=/var/lib/$NAME 

# You may pass JVM startup parameters to Java here. If unset, the default 
# options (-Djava.awt.headless=true -Xmx128m) will be used. 
JAVA_OPTS=-Djava.awt.headless=true -Xmx128m 

# Use a CMS garbage collector for improved response time 
# JAVA_OPTS=${JAVA_OPTS} -XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC 
JAVA_OPTS=${JAVA_OPTS} -Xnoclassgc -Xloggc:/var/log/tomcat6/gc.log 


# When using the CMS garbage collector, you should enable the following option 
# if you run Tomcat on a machine with exactly one CPU chip that contains one 
# or two cores. 
#JAVA_OPTS=$JAVA_OPTS -XX:+CMSIncrementalMode 

# To enable remote debugging uncomment the following line. 
# You will then be able to use a java debugger on port 8000. 
#JAVA_OPTS=${JAVA_OPTS} -Xdebug 
-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n 

# Java compiler to use for translating JavaServer Pages (JSPs). You can use all 
# compilers that are accepted by Ant's build.compiler property. 
#JSP_COMPILER=javac 

# Use the Java security manager? (yes/no, default: no) 
#TOMCAT6_SECURITY=no 

# Number of days to keep logfiles in /var/log/tomcat6. Default is 14 days. 
#LOGFILE_DAYS=14 

# Location of the JVM temporary directory 
# WARNING: This directory will be destroyed and recreated at every startup ! 
#JVM_TMP=/tmp/tomcat6-temp 


I'd really appreciate if I could get a quick reply, as we're not being able to 
solve this on our own :3 

Thanks! 

Kevin

RE: Issues with Memory Leaks on Tomcat 6.0.28

2010-09-23 Thread Caldarale, Charles R

 From: Kevin Mai [mailto:k...@mrecic.gov.ar] 
 Subject: Issues with Memory Leaks on Tomcat 6.0.28

 I'm getting this error on my tomcat installation: 

 SEVERE: Error listenerStart 

The above is the real problem.  (Note that you didn't give us the interesting 
part of the log, including the timestamp for the above entry and any stack 
trace that might actually tell us what the real error is.)

 Sep 23, 2010 2:29:40 PM org.apache.catalina.core.StandardContext start 
 SEVERE: Context [/Simon] startup failed due to previous errors 

The above is a result of the first problem.

 Sep 23, 2010 2:29:40 PM org.apache.catalina.loader.WebappClassLoader 
 clearThreadLocalMap 
 SEVERE: The web application [/Simon] created a ThreadLocal

The above is just telling you that Tomcat is cleaning up the mess of the 
unstartable webapp, because the webapp failed to do so itself (quite possibly 
because the listener is broken).

Fix the problem (your listener), not the symptom.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

Re: Issues with Memory Leaks on Tomcat 6.0.28

2010-09-23 Thread Kevin Mai

This is the whole output:


INFO: Pausing Coyote HTTP/1.1 on http-8080
Sep 23, 2010 2:57:02 PM org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina
Sep 23, 2010 2:57:02 PM org.apache.catalina.core.StandardContext stop
INFO: Container 
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/Simon] has not 
been started
Sep 23, 2010 2:57:02 PM org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8080
Sep 23, 2010 2:57:05 PM org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting 
property 'debug' to '0' did not find a matching property.
Sep 23, 2010 2:57:06 PM org.apache.tomcat.util.digester.Digester endElement
WARNING:   No rules found matching 'Server/Service/Engine/Host/Context/Logger'.
Sep 23, 2010 2:57:06 PM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
Sep 23, 2010 2:57:06 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 1181 ms
Sep 23, 2010 2:57:06 PM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Sep 23, 2010 2:57:06 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.28
Sep 23, 2010 2:57:09 PM org.apache.catalina.core.StandardContext start
SEVERE: Error listenerStart
Sep 23, 2010 2:57:09 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [/Simon] startup failed due to previous errors
Sep 23, 2010 2:57:09 PM org.apache.catalina.loader.WebappClassLoader 
clearReferencesJdbc
SEVERE: The web application [/Simon] registered the JBDC driver 
[com.mysql.jdbc.Driver] but failed to unregister it when the web application 
was stopped. To prevent a memory leak, the JDBC Driver has been forcibly 
unregistered.
Sep 23, 2010 2:57:09 PM org.apache.catalina.loader.WebappClassLoader 
clearThreadLocalMap
SEVERE: The web application [/Simon] created a ThreadLocal with key of type 
[java.lang.ThreadLocal] (value [java.lang.threadlo...@3e0d1329]) and a value of 
type [com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl] (value 
[com.ibatis.sqlmap.engine.impl.sqlmapsessioni...@4c650892]) but failed to 
remove it when the web application was stopped. This is very likely to create a 
memory leak.
Sep 23, 2010 2:57:09 PM org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor host-manager.xml
Sep 23, 2010 2:57:10 PM org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor examples.xml
Sep 23, 2010 2:57:10 PM org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor ROOT.xml
Sep 23, 2010 2:57:10 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory Simon_WEB.war
Sep 23, 2010 2:57:12 PM org.apache.catalina.core.StandardContext start
SEVERE: Error listenerStart
Sep 23, 2010 2:57:12 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [/Simon_WEB.war] startup failed due to previous errors
Sep 23, 2010 2:57:12 PM org.apache.catalina.loader.WebappClassLoader 
clearThreadLocalMap
SEVERE: The web application [/Simon_WEB.war] created a ThreadLocal with key of 
type [java.lang.ThreadLocal] (value [java.lang.threadlo...@23b17d49]) and a 
value of type [com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl] (value 
[com.ibatis.sqlmap.engine.impl.sqlmapsessioni...@599855ed]) but failed to 
remove it when the web application was stopped. This is very likely to create a 
memory leak.
Sep 23, 2010 2:57:12 PM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
Sep 23, 2010 2:57:12 PM org.apache.catalina.startup.Catalina start

I don't know where to look at to be honest..

- Mensaje original -
De: Charles R Caldarale chuck.caldar...@unisys.com
Para: Tomcat Users List users@tomcat.apache.org
Enviados: Jueves, 23 de Septiembre 2010 14:45:16
Asunto: RE: Issues with Memory Leaks on Tomcat 6.0.28

 From: Kevin Mai [mailto:k...@mrecic.gov.ar]
 Subject: Issues with Memory Leaks on Tomcat 6.0.28

 I'm getting this error on my tomcat installation:

 SEVERE: Error listenerStart

The above is the real problem. (Note that you didn't give us the
interesting part of the log, including the timestamp for the above entry
and any stack trace that might actually tell us what the real error is.)

 Sep 23, 2010 2:29:40 PM org.apache.catalina.core.StandardContext start
 SEVERE: Context [/Simon] startup failed due to previous errors

The above is a result of the first problem.

 Sep 23, 2010 2:29:40 PM org.apache.catalina.loader.WebappClassLoader
 clearThreadLocalMap
 SEVERE: The web application [/Simon] created a ThreadLocal

The above is just telling you that Tomcat is cleaning up the mess of the
unstartable webapp, because the webapp failed to do so itself (quite
possibly because the listener is broken).

Fix the problem (your listener

Re: Issues with Memory Leaks on Tomcat 6.0.28

2010-09-23 Thread Mark Thomas

On 23/09/2010 10:58, Kevin Mai wrote:
 Sep 23, 2010 2:57:09 PM org.apache.catalina.core.StandardContext start
 SEVERE: Error listenerStart

The stack trace for this will be in the localhost log (or maybe an app
specific log).

Mark



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

Re: Issues with Memory Leaks on Tomcat 6.0.28

2010-09-23 Thread Mark Eggers

I'll do some of this inline:


 WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting 
property 'debug'
  to '0' did not find a matching property.

Two things here:

1. Place your context in a META-INF/context.xml file in your web application, 
not in server.xml
2. Remove the debug attribute, since it hasn't been valid for a long time.

 WARNING:   No rules found matching 
'Server/Service/Engine/Host/Context/Logger'.


I don't see a reference to a Logger in the Context documentation for 5.5, 6.0, 
0r 7.0. If you're trying to log at the Context level, take a look at the 
documents for your version of Tomcat (which you've not mentioned) and add the 
appropriate Valve element.

 SEVERE: Error listenerStart

This is the problem (as pointed out before). The code you're using in your 
Listener isn't working as expected. I suspect that you're trying to start up 
iBatis (now MyBatis), and that the code is failing.
 
 SEVERE: The web application [/Simon] created a ThreadLocal with key of type
 [java.lang.ThreadLocal] (value [java.lang.threadlo...@3e0d1329]) and a value 
 of 
type 
 [com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl] (value 
 [com.ibatis.sqlmap.engine.impl.sqlmapsessioni...@4c650892]) but failed to 
remove it when 
 the web application was stopped. This is very likely to create a memory leak.

 SEVERE: The web application [/Simon_WEB.war] created a ThreadLocal with key 
 of 
type 
 [java.lang.ThreadLocal] (value [java.lang.threadlo...@23b17d49]) and a value 
 of 
type 
 [com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl] (value 
 [com.ibatis.sqlmap.engine.impl.sqlmapsessioni...@599855ed]) but failed to 
remove it when 
 the web application was stopped. This is very likely to create a memory leak.

This is fallout from your failed listener (as has been pointed out).

When you write a listener class, you have both a 
contextInitialized(ServletContextEvent sce) and a 
contextDestroyed(ServletContextEvent sce) method.

It looks like your contextInitialized method is failing, and you've not written 
a contextDestroyed method. You'll need to fix the first, and then write the 
second so that when the context is destroyed (like undeploying the 
application), 
you shut down all of your resources gracefully.

I've not used iBatis, so I am not aware of how the listener should be written. 
I've done this for Hibernate.

I'm also guessing that you're setting up iBatis to control the database pooling 
and access. You can let Tomcat manage the connection pool with iBatis. This may 
simplify your listener code somewhat. An iBatis thread concerning that can be 
found here:

http://markmail.org/message/pocthjsiw4cdhohj#query:+page:1+mid:pocthjsiw4cdhohj+state:results


So:

1. Fix your contextInitialized method
2. Write a contextDestroyed method
3. Configure iBatis to use Tomcat's database pooling (which may eliminate the 
need for 2)

. . . . just my two cents.

/mde/


  


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

Re: Issues with Memory Leaks on Tomcat 6.0.28

2010-09-23 Thread Kevin Mai

Catalina was misconfigured, as the dev-team placed some properties on a
/home/blabla path :S

Thanks for helping me out anyway!

- Mensaje original -
De: Mark Eggers its_toas...@yahoo.com
Para: Tomcat Users List users@tomcat.apache.org
Enviados: Jueves, 23 de Septiembre 2010 15:44:21
Asunto: Re: Issues with Memory Leaks on Tomcat 6.0.28

I'll do some of this inline:

WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context}
Setting
property 'debug'
to '0' did not find a matching property.

Two things here:

1. Place your context in a META-INF/context.xml file in your web
application, not in server.xml
2. Remove the debug attribute, since it hasn't been valid for a long
time.

WARNING: No rules found matching
'Server/Service/Engine/Host/Context/Logger'.

I don't see a reference to a Logger in the Context documentation for
5.5, 6.0,
0r 7.0. If you're trying to log at the Context level, take a look at the
documents for your version of Tomcat (which you've not mentioned) and
add the
appropriate Valve element.

SEVERE: Error listenerStart

This is the problem (as pointed out before). The code you're using in
your Listener isn't working as expected. I suspect that you're trying to
start up
iBatis (now MyBatis), and that the code is failing.

SEVERE: The web application [/Simon] created a ThreadLocal with key of
type [java.lang.ThreadLocal] (value [java.lang.threadlo...@3e0d1329])
and a value of
type
[com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl] (value
[com.ibatis.sqlmap.engine.impl.sqlmapsessioni...@4c650892]) but failed
to
remove it when
the web application was stopped. This is very likely to create a
memory leak.

SEVERE: The web application [/Simon_WEB.war] created a ThreadLocal
with key of
type
[java.lang.ThreadLocal] (value [java.lang.threadlo...@23b17d49]) and a
value of
type
[com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl] (value
[com.ibatis.sqlmap.engine.impl.sqlmapsessioni...@599855ed]) but failed
to
remove it when
the web application was stopped. This is very likely to create a
memory leak.

This is fallout from your failed listener (as has been pointed out).

When you write a listener class, you have both a
contextInitialized(ServletContextEvent sce) and a
contextDestroyed(ServletContextEvent sce) method.

It looks like your contextInitialized method is failing, and you've not
written a contextDestroyed method. You'll need to fix the first, and
then write the
second so that when the context is destroyed (like undeploying the
application), you shut down all of your resources gracefully.

I've not used iBatis, so I am not aware of how the listener should be
written. I've done this for Hibernate.

I'm also guessing that you're setting up iBatis to control the database
pooling and access. You can let Tomcat manage the connection pool with
iBatis. This may
simplify your listener code somewhat. An iBatis thread concerning that
can be
found here:

http://markmail.org/message/pocthjsiw4cdhohj#query:+page:1+mid:pocthjsiw4cdhohj+state:results

So:

1. Fix your contextInitialized method
2. Write a contextDestroyed method
3. Configure iBatis to use Tomcat's database pooling (which may
eliminate the
need for 2)

. . . . just my two cents.

/mde/

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

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

Stopping a Timer in contextDestroyed() to avoid memory leaks results in a NullPointerException

2010-05-26 Thread devnull

Hi,

Thanks for reading this.

I am developing a webapp and do not understand the following:
In my app, I create a Timer when the servlet starts.
When tomcat stops, I try to stop the timer in order to avoid memory leaks.

My question is: why do I get a NullPointerException while trying to access 
mytimer in contextDestroyed().

The simplified code:

public class myclass extends HttpServlet implements ServletContextListener {

   java.util.Timer mytimer;
   int testint;

   public void init() throws ServletException {
   mytimer = new Timer(__test__);
  TimerTask taskPerformer = new TimerTask() { public void run() { 
whatever_function(); } };
   mytimer.scheduleAtFixedRate(taskPerformer, 10, 10, 864000);
  testint = 12;
   }

   public void contextDestroyed(ServletContextEvent event) {
      System.out.println(Inside contextDestroyed, testint=+testint);
      try {
         mytimer.cancel();
      }
      catch (Exception e) {
         System.out.println(An error occurred inside 
contextDestroyed(): +e);
      }
}

   public void contextInitialized(ServletContextEvent event) {
  // Nothing here
   }

   public void destroy() {
     // Nothing here
   }
}

The Output:
May 26, 2010 8:06:30 PM org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina
Inside contextDestroyed(), testing=12
An error occurred inside contextDestroyed(): java.lang.NullPointerException
May 26, 2010 8:06:30 PM org.apache.catalina.loader.WebappClassLoader 
clearReferencesThreads
SEVERE: A web application appears to have started a thread named [__test__] but 
has failed to stop it. This is very likely to create a memory leak.

What disturbs me, is that my other variable testint is accessible within 
contextDestroyed, but not mytimer.

If I save my timer in init() like this:

  ServletContext sc = getServletContext();
 sc.setAttribute(mytimer, mytimer)

and if I modify contextDestroyed() so that it accesses my timer through 
ServletContext

 ServletContext context = event.getServletContext();
 Timer mytimer2 = (Timer)context.getAttribute(mytimer);

then I have no problem stopping it, making the tomcat warning disappear.
I'd like to understand why it is so.

Thank you very much in advance
___
NEU: WEB.DE DSL für 19,99 EUR/mtl. und ohne Mindest-Laufzeit!
http://produkte.web.de/go/02/

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

Re: Stopping a Timer in contextDestroyed() to avoid memory leaks results in a NullPointerException

2010-05-26 Thread Pid

On 26/05/2010 19:43, devn...@web.de wrote:
 Hi,
 
 Thanks for reading this.
 
 I am developing a webapp and do not understand the following:
 In my app, I create a Timer when the servlet starts.
 When tomcat stops, I try to stop the timer in order to avoid memory leaks.
 
 My question is: why do I get a NullPointerException while trying to access 
 mytimer in contextDestroyed().
 
 The simplified code:
 
 public class myclass extends HttpServlet implements ServletContextListener {
 
java.util.Timer mytimer;
int testint;
 
public void init() throws ServletException {
mytimer = new Timer(__test__);
   TimerTask taskPerformer = new TimerTask() { public void run() { 
 whatever_function(); } };
mytimer.scheduleAtFixedRate(taskPerformer, 10, 10, 864000);
   testint = 12;
}

Why mix  match the Servlet and ServletContextListener methods?


p

public void contextDestroyed(ServletContextEvent event) {
   System.out.println(Inside contextDestroyed, testint=+testint);
   try {
  mytimer.cancel();
   }
   catch (Exception e) {
  System.out.println(An error occurred inside 
 contextDestroyed(): +e);
   }
 }
 
public void contextInitialized(ServletContextEvent event) {
   // Nothing here
}
 
public void destroy() {
  // Nothing here
}
 }
 
 The Output:
 May 26, 2010 8:06:30 PM org.apache.catalina.core.StandardService stop
 INFO: Stopping service Catalina
 Inside contextDestroyed(), testing=12
 An error occurred inside contextDestroyed(): java.lang.NullPointerException
 May 26, 2010 8:06:30 PM org.apache.catalina.loader.WebappClassLoader 
 clearReferencesThreads
 SEVERE: A web application appears to have started a thread named [__test__] 
 but has failed to stop it. This is very likely to create a memory leak.
 
 What disturbs me, is that my other variable testint is accessible within 
 contextDestroyed, but not mytimer.
 
 If I save my timer in init() like this:
 
   ServletContext sc = getServletContext();
  sc.setAttribute(mytimer, mytimer)
 
 and if I modify contextDestroyed() so that it accesses my timer through 
 ServletContext
 
  ServletContext context = event.getServletContext();
  Timer mytimer2 = (Timer)context.getAttribute(mytimer);
 
 then I have no problem stopping it, making the tomcat warning disappear.
 I'd like to understand why it is so.
 
 Thank you very much in advance
 ___
 NEU: WEB.DE DSL für 19,99 EUR/mtl. und ohne Mindest-Laufzeit!
 http://produkte.web.de/go/02/
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 




signature.asc
Description: OpenPGP digital signature

Re: Stopping a Timer in contextDestroyed() to avoid memory leaks results in a NullPointerException

2010-05-26 Thread roberto calosino

Hi,

thank you for your reply.
First I'd like to say that I do implement ServletContextListener at all 
beacause destroy() fires after the tomcat warnings.

That being said, on this website: 
http://stackoverflow.com/questions/2255884/jython-and-implementing-httpservlet-contextinitialized
 
is written that  You can optionally also let your servlet both extend 
HttpServlet and implement ServletContextListener
It is also said that it is not always considered a good practice.

Why is that so ?
Would that be an explanation why in my case I can access some variables but 
others not ?

Thank you for your help.

-Ursprüngliche Nachricht-
Von: Pid p...@pidster.com
Gesendet: 26.05.2010 20:45:53
An: Tomcat Users List users@tomcat.apache.org
Betreff: Re: Stopping a Timer in contextDestroyed() to avoid memory leaks 
results in a NullPointerException

On 26/05/2010 19:43, devn...@web.de wrote:
 Hi,
 
 Thanks for reading this.
 
 I am developing a webapp and do not understand the following:
 In my app, I create a Timer when the servlet starts.
 When tomcat stops, I try to stop the timer in order to avoid memory leaks.
 
 My question is: why do I get a NullPointerException while trying to access 
 mytimer in contextDestroyed().
 
 The simplified code:
 
 public class myclass extends HttpServlet implements ServletContextListener {
 
java.util.Timer mytimer;
int testint;
 
public void init() throws ServletException {
mytimer = new Timer(__test__);
   TimerTask taskPerformer = new TimerTask() { public void run() 
 { whatever_function(); } };
mytimer.scheduleAtFixedRate(taskPerformer, 10, 10, 864000);
   testint = 12;
}

Why mix  match the Servlet and ServletContextListener methods?


p

public void contextDestroyed(ServletContextEvent event) {
   System.out.println(Inside contextDestroyed, 
 testint=+testint);
   try {
  mytimer.cancel();
   }
   catch (Exception e) {
  System.out.println(An error occurred inside 
 contextDestroyed(): +e);
   }
 }
 
public void contextInitialized(ServletContextEvent event) {
   // Nothing here
}
 
public void destroy() {
  // Nothing here
}
 }
 
 The Output:
 May 26, 2010 8:06:30 PM org.apache.catalina.core.StandardService stop
 INFO: Stopping service Catalina
 Inside contextDestroyed(), testing=12
 An error occurred inside contextDestroyed(): java.lang.NullPointerException
 May 26, 2010 8:06:30 PM org.apache.catalina.loader.WebappClassLoader 
 clearReferencesThreads
 SEVERE: A web application appears to have started a thread named [__test__] 
 but has failed to stop it. This is very likely to create a memory leak.
 
 What disturbs me, is that my other variable testint is accessible within 
 contextDestroyed, but not mytimer.
 
 If I save my timer in init() like this:
 
   ServletContext sc = getServletContext();
  sc.setAttribute(mytimer, mytimer)
 
 and if I modify contextDestroyed() so that it accesses my timer through 
 ServletContext
 
  ServletContext context = event.getServletContext();
  Timer mytimer2 = (Timer)context.getAttribute(mytimer);
 
 then I have no problem stopping it, making the tomcat warning disappear.
 I'd like to understand why it is so.
 
 Thank you very much in advance
___
GRATIS: Movie-Flat mit über 300 Top-Videos. Für WEB.DE Nutzer
dauerhaft kostenlos! Jetzt freischalten unter http://movieflat.web.de


signature.asc
Description: OpenPGP digital signature

RE: Stopping a Timer in contextDestroyed() to avoid memory leaks results in a NullPointerException

2010-05-26 Thread Caldarale, Charles R

 From: roberto calosino [mailto:devn...@web.de]
 Subject: Re: Stopping a Timer in contextDestroyed() to avoid memory
 leaks results in a NullPointerException

 You can optionally also let your servlet both extend
 HttpServlet and implement ServletContextListener
 It is also said that it is not always considered a 
 good practice.

 Why is that so ?

Because, as you have inadvertently discovered, separate instances of the class 
are created for each purpose.  If you make the mytimer field static (along with 
any others you want to use in both instances) you won't have a problem.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

Re: Stopping a Timer in contextDestroyed() to avoid memory leaks results in a NullPointerException

2010-05-26 Thread Emeric Vernat


Hi,

You could also eliminate the mix  match and add a finally, with the 
following servlet code for example:


public void init() throws ServletException {
   boolean initOk = false;
mytimer = new Timer(__test__);
try {
TimerTask taskPerformer = new TimerTask() { public void 
run() { whatever_function(); } };
mytimer.scheduleAtFixedRate(taskPerformer, 10, 10, 
864000);
testint = 12;
initOk = true; // as last
} finally {
if (!initOk) {
mytimer.cancel();
}
}
 }

public void destroy() {
System.out.println(Inside destroy, testint=+testint);
try {
mytimer.cancel();
} catch (Exception e) {
System.out.println(An error occurred inside 
contextDestroyed(): +e);

}
}

I added a finally / cancel in the init method, because as Kostantin 
Kolinko said yesterday, if there is an exception in the init method 
after a timer creation, then the destroy method is not called and the 
timer is never canceled even if your webapp is unusable (and Tomcat 
6.0.26 will warn about that timer).


I supposed here that your init method is not so simplified.

bye, Emeric

Le 26/05/2010 21:26, Caldarale, Charles R a écrit :

From: roberto calosino [mailto:devn...@web.de]
Subject: Re: Stopping a Timer in contextDestroyed() to avoid memory
leaks results in a NullPointerException

You can optionally also let your servlet both extend
HttpServlet and implement ServletContextListener
It is also said that it is not always considered a
good practice.

Why is that so ?
 

Because, as you have inadvertently discovered, separate instances of the class 
are created for each purpose.  If you make the mytimer field static (along with 
any others you want to use in both instances) you won't have a problem.

  - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

   




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

Re: Stopping a Timer in contextDestroyed() to avoid memory leaks results in a NullPointerException

2010-05-26 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Emeric,

On 5/26/2010 3:52 PM, Emeric Vernat wrote:
 You could also eliminate the mix  match and add a finally, with the
 following servlet code for example:
 
 public void init() throws ServletException {
boolean initOk = false;
 mytimer = new Timer(__test__);
 try {
 TimerTask taskPerformer = new TimerTask() { public void
 run() { whatever_function(); } };
mytimer.scheduleAtFixedRate(taskPerformer, 10,
 10, 864000);
 testint = 12;
 initOk = true; // as last
 } finally {
 if (!initOk) {
 mytimer.cancel();
 }
 }
  }

Uh what? I'm sure that does something, but ... I'm not sure what it
could be.

Could the OP show us the stack trace relative to the warning coming from
Tomcat? I'd bet that Tomcat's stop leaks procedure is clearing-out a
static Timer reference and /then/ the ServletContextListener is trying
to access it. That's not supposed to happen, I'm guessing: the stop
leaks stuff should run after all ServletContextListeners been notified
that the context is coming down.

I'm sure there is more useful information in the log file that we're not
seeing.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkv9haYACgkQ9CaO5/Lv0PCM1QCgvc2Y/SD1UJntGSBMJzo7ThBx
Ty8An3wul/JusKxqjB3fRZRdikJjdI8l
=z2/W
-END PGP SIGNATURE-

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

RE: Stopping a Timer in contextDestroyed() to avoid memory leaks results in a NullPointerException

2010-05-26 Thread Caldarale, Charles R

 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Subject: Re: Stopping a Timer in contextDestroyed() to avoid memory
 leaks results in a NullPointerException

 I'd bet that Tomcat's stop leaks procedure is clearing-out a
 static Timer reference and /then/ the ServletContextListener is
 trying to access it.

No, it's because the same class was used as both a servlet and a listener, and 
the field holding the timer reference was not static.  Tomcat instantiates 
separate objects for the servlet and listener; the timer reference was set in 
the servlet instance, but still void in the listener instance.

An example of why not to do asymmetrical programming.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

Re: Stopping a Timer in contextDestroyed() to avoid memory leaks results in a NullPointerException

2010-05-26 Thread Emeric Vernat


Hi Chris,

The initial submitter had a HttpServlet implementing 
ServletContextListener with a non static timer, and in fact there were 2 
instances of the class: the contextDestroyed method of the 
servletContextListener instance can't cancel the timer of the 
httpServlet instance (NullPointerException as he said) then Tomcat 
6.0.26 stopped the leak.
As Pid said there is a mix and match. To fix it, the init and destroy 
methods of the HttpServlet can create and cancel the timer cleanly (no 
more NullPointerException and no more leak).


Then I just wanted to suggest a finally and a cancel in the init method 
to be cleaner (because if there is an OutOfMemoryError or something like 
that in scheduleAtFixedRate, then the leak appears again except that 
Tomcat 6.0.26 stops it. Thanks Konstantin).


bye, Emeric


Le 26/05/2010 22:33, Christopher Schultz a écrit :

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Emeric,

On 5/26/2010 3:52 PM, Emeric Vernat wrote:
   

You could also eliminate the mix  match and add a finally, with the
following servlet code for example:

public void init() throws ServletException {
boolean initOk = false;
 mytimer = new Timer(__test__);
 try {
 TimerTask taskPerformer = new TimerTask() { public void
run() { whatever_function(); } };
mytimer.scheduleAtFixedRate(taskPerformer, 10,
10, 864000);
 testint = 12;
 initOk = true; // as last
 } finally {
 if (!initOk) {
 mytimer.cancel();
 }
 }
  }
 

Uh what? I'm sure that does something, but ... I'm not sure what it
could be.

Could the OP show us the stack trace relative to the warning coming from
Tomcat? I'd bet that Tomcat's stop leaks procedure is clearing-out a
static Timer reference and /then/ the ServletContextListener is trying
to access it. That's not supposed to happen, I'm guessing: the stop
leaks stuff should run after all ServletContextListeners been notified
that the context is coming down.

I'm sure there is more useful information in the log file that we're not
seeing.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkv9haYACgkQ9CaO5/Lv0PCM1QCgvc2Y/SD1UJntGSBMJzo7ThBx
Ty8An3wul/JusKxqjB3fRZRdikJjdI8l
=z2/W
-END PGP SIGNATURE-

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




   




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

Re: Stopping a Timer in contextDestroyed() to avoid memory leaks results in a NullPointerException

2010-05-26 Thread Mark Thomas

On 26/05/2010 21:33, Christopher Schultz wrote:
 I'd bet that Tomcat's stop leaks procedure is clearing-out a
 static Timer reference and /then/ the ServletContextListener is trying
 to access it.

I'll take that bet. How much ;)

 That's not supposed to happen, I'm guessing: the stop
 leaks stuff should run after all ServletContextListeners been notified
 that the context is coming down.

No need for guess work. This is *open* source after all.
http://svn.apache.org/viewvc/tomcat/tc6.0.x/tags/TOMCAT_6_0_26/java/org/apache/catalina/core/StandardContext.java?view=annotate

In particular, lines:
- 4569 the stop() method
- 4615 stopping the listeners
- 4649 stopping the loader (which will stop the class loader, which
triggers the clearReferences() method which will stop the timer threads)

Mark



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

Re: Tips on tracking down memory leaks

2010-01-13 Thread Greg McCane

Thanks Chuck.

Is there any danger in taking a heap dump on our system running in production? 
Will it cause a significant performance hit or other nasty?

Thanks again,
Greg





From: Caldarale, Charles R chuck.caldar...@unisys.com
To: Tomcat Users List users@tomcat.apache.org
Sent: Tue, January 12, 2010 11:31:16 PM
Subject: RE: Tips on tracking down memory leaks

 From: Greg McCane [mailto:gregmcc...@yahoo.ca]
 Subject: Tips on tracking down memory leaks
 
 The memory growth appears to be in large chunks rather 
 than slow, steady growth.

Use a heap profiler to find out what's eating up the space and who is 
allocating it.  Even the simple one (hprof) included in the 1.5 JDK will tell 
you that.  Better ones (e.g., jhat) are available in 1.6, if you're willing to 
move up.  There are also numerous 3rd-party profilers available, with YourKit 
being a favorite of many.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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


  __
The new Internet Explorer® 8 - Faster, safer, easier.  Optimized for Yahoo!  
Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/

Re: Tips on tracking down memory leaks

2010-01-13 Thread Greg McCane

Thanks a lot Joe, we are checking our code based on your suggestions.

Cheers,
Greg





From: Joseph Morgan joseph.mor...@ignitesales.com
To: Tomcat Users List users@tomcat.apache.org
Sent: Tue, January 12, 2010 11:15:54 PM
Subject: RE: Tips on tracking down memory leaks

Greg, you've just awakened a 900 lb gorilla!

My guess, based upon your description of the problem as large chunks at
a time, is something related to reading and caching data, and this is
why PMD and profiling tools won't help. 

Therefore, look at all the code accessing data from whatever storage you
use (DB, File?), and find out where that data flows.  I'd also guess is
that someone is storing data in the context, maybe as a cache, or just
because they don't know any better. So search for setAttribute calls
in the code and trace the associated object.  If that object points to
the servlet context, then mark it as a candidate.  This could be
complicated by JSPs (if you are using them), because they could be
storing data within the application scope within JSP pages (very bad
practice, but very widely used).  Also check out tag libraries, because
it can be done there too.

Check your session timeout to make sure it isn't too high (however, you
did say it isn't slow growth, but check anyway).

However, we could literally guess all day long, as there are dozens of
ways code can eat up memory.

Joe

-Original Message-
From: Greg McCane [mailto:gregmcc...@yahoo.ca] 
Sent: Monday, January 11, 2010 8:33 PM
To: users@tomcat.apache.org
Subject: Tips on tracking down memory leaks

Hi Everyone,

I am running tomcat 5.5 on Debian Linux (uname says Linux
2.6.26-2-amd64, /etc/debian_version says 5.0.2). The JVM version is
1.5.0_14-b03.

We have 9 servlets running.

The tomcat process itself is managed by monit.

We see tomcat memory usage growing over time and have set monit to
automatically restart it (using the /etc/init.d/tomcat5.5 startup
script) when memory usage reaches 2.8 GB. It takes about 20 hours to get
to this point. This is an attempt to avoid a tomcat crash/hang resulting
in an outage for our users. The memory growth appears to be in large
chunks rather than slow, steady growth.

We have turned on incremental garbage collection with the following
options:

-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode 
-XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 
-XX:+CMSIncrementalDutyCycle=10 -XX:-TraceClassUnloading
-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

The JVM heap size is set with: -Xmx3072M -Xms1024M 

We have checked our code using pmd and have profiled it using TPT and
Eclipse in our development environment. We have made improvements as a
result of the findings from these tools, but we are still having
problems.

Any suggestions for next steps to help us get to the root cause of this
problem?

Thanks,
Greg


  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/

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


  __
Be smarter than spam. See how smart SpamGuard is at giving junk email the boot 
with the All-new Yahoo! Mail.  Click on Options in Mail and switch to New Mail 
today or register for free at http://mail.yahoo.ca

Re: Tips on tracking down memory leaks

2010-01-13 Thread Ronald Klop


No. But historical results are not a guarantee for the future.

It is very easy to make a heapdump with jmap and analyze it with MAT 
(http://www.eclipse.org/mat/) or other tools as suggested by others on this 
list.

Ronald.


Op woensdag, 13 januari 2010 11:44 schreef Greg McCane gregmcc...@yahoo.ca:


 


Thanks Chuck.

Is there any danger in taking a heap dump on our system running in production? 
Will it cause a significant performance hit or other nasty?

Thanks again,
Greg





From: Caldarale, Charles R chuck.caldar...@unisys.com
To: Tomcat Users List users@tomcat.apache.org
Sent: Tue, January 12, 2010 11:31:16 PM
Subject: RE: Tips on tracking down memory leaks

 From: Greg McCane [mailto:gregmcc...@yahoo.ca]
 Subject: Tips on tracking down memory leaks
 
 The memory growth appears to be in large chunks rather 
 than slow, steady growth.


Use a heap profiler to find out what's eating up the space and who is 
allocating it.  Even the simple one (hprof) included in the 1.5 JDK will tell 
you that.  Better ones (e.g., jhat) are available in 1.6, if you're willing to 
move up.  There are also numerous 3rd-party profilers available, with YourKit 
being a favorite of many.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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


  __
The new Internet Explorer® 8 - Faster, safer, easier.  Optimized for Yahoo!  
Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/

RE: Tips on tracking down memory leaks

2010-01-13 Thread Caldarale, Charles R

 From: Greg McCane [mailto:gregmcc...@yahoo.ca]
 Subject: Re: Tips on tracking down memory leaks

 Is there any danger in taking a heap dump on our system running in
 production? Will it cause a significant performance hit or other nasty?

No; taking a heap dump will cause a momentary blip (threads have to be 
suspended briefly), but you're likely not to even notice it.  Running a heap 
profiler can impact performance, if you're CPU-limited.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

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

RE: Tips on tracking down memory leaks

2010-01-12 Thread Joseph Morgan

Greg, you've just awakened a 900 lb gorilla!

My guess, based upon your description of the problem as large chunks at
a time, is something related to reading and caching data, and this is
why PMD and profiling tools won't help. 

Therefore, look at all the code accessing data from whatever storage you
use (DB, File?), and find out where that data flows.  I'd also guess is
that someone is storing data in the context, maybe as a cache, or just
because they don't know any better. So search for setAttribute calls
in the code and trace the associated object.  If that object points to
the servlet context, then mark it as a candidate.  This could be
complicated by JSPs (if you are using them), because they could be
storing data within the application scope within JSP pages (very bad
practice, but very widely used).  Also check out tag libraries, because
it can be done there too.

Check your session timeout to make sure it isn't too high (however, you
did say it isn't slow growth, but check anyway).

However, we could literally guess all day long, as there are dozens of
ways code can eat up memory.

Joe

-Original Message-
From: Greg McCane [mailto:gregmcc...@yahoo.ca] 
Sent: Monday, January 11, 2010 8:33 PM
To: users@tomcat.apache.org
Subject: Tips on tracking down memory leaks

Hi Everyone,

I am running tomcat 5.5 on Debian Linux (uname says Linux
2.6.26-2-amd64, /etc/debian_version says 5.0.2). The JVM version is
1.5.0_14-b03.

We have 9 servlets running.

The tomcat process itself is managed by monit.

We see tomcat memory usage growing over time and have set monit to
automatically restart it (using the /etc/init.d/tomcat5.5 startup
script) when memory usage reaches 2.8 GB. It takes about 20 hours to get
to this point. This is an attempt to avoid a tomcat crash/hang resulting
in an outage for our users. The memory growth appears to be in large
chunks rather than slow, steady growth.

We have turned on incremental garbage collection with the following
options:

-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode 
-XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 
-XX:+CMSIncrementalDutyCycle=10 -XX:-TraceClassUnloading
-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

The JVM heap size is set with: -Xmx3072M -Xms1024M 

We have checked our code using pmd and have profiled it using TPT and
Eclipse in our development environment. We have made improvements as a
result of the findings from these tools, but we are still having
problems.

Any suggestions for next steps to help us get to the root cause of this
problem?

Thanks,
Greg


  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/

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

RE: Tips on tracking down memory leaks

2010-01-12 Thread Caldarale, Charles R

 From: Greg McCane [mailto:gregmcc...@yahoo.ca]
 Subject: Tips on tracking down memory leaks

 The memory growth appears to be in large chunks rather 
 than slow, steady growth.

Use a heap profiler to find out what's eating up the space and who is 
allocating it.  Even the simple one (hprof) included in the 1.5 JDK will tell 
you that.  Better ones (e.g., jhat) are available in 1.6, if you're willing to 
move up.  There are also numerous 3rd-party profilers available, with YourKit 
being a favorite of many.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

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

Tips on tracking down memory leaks

2010-01-11 Thread Greg McCane

Hi Everyone,

I am running tomcat 5.5 on Debian Linux (uname says Linux 2.6.26-2-amd64, 
/etc/debian_version says 5.0.2). The JVM version is 1.5.0_14-b03.

We have 9 servlets running.

The tomcat process itself is managed by monit.

We see tomcat memory usage growing over time and have set monit to 
automatically restart it (using the /etc/init.d/tomcat5.5 startup script) when 
memory usage reaches 2.8 GB. It takes about 20 hours to get to this point. This 
is an attempt to avoid a tomcat crash/hang resulting in an outage for our 
users. The memory growth appears to be in large chunks rather than slow, steady 
growth.

We have turned on incremental garbage collection with the following options:

-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode 
-XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 
-XX:+CMSIncrementalDutyCycle=10 -XX:-TraceClassUnloading
-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

The JVM heap size is set with: -Xmx3072M -Xms1024M 

We have checked our code using pmd and have profiled it using TPT and Eclipse 
in our development environment. We have made improvements as a result of the 
findings from these tools, but we are still having problems.

Any suggestions for next steps to help us get to the root cause of this problem?

Thanks,
Greg


  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/

Re: Tomcat Memory Leaks

2009-03-06 Thread Mark Thomas

Diego Rodríguez Martín wrote:
 Hi,
 
I'm not an expert, but I think Tomcat 4.X is not compatible with JDK
 1.5.

That is not correct. Tomcat 4.x works quite happily with 1.4, 1.5 and
1.6. I have also had a number of recent versions running on 1.3 and 1.2
JVMs although without extensive testing.

Mark



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

Re: memory leaks (Tomcat 5.5.20 and JDK 1.6)

2007-08-14 Thread Ronald Klop


Do you monitor the memory usage over time?
Is it steadily increasing? Or does it peak at one moment?
Ronald.

On Fri Aug 10 20:36:44 CEST 2007 Tomcat Users List users@tomcat.apache.org 
wrote:

Hello Tomcat Users ,
Our web application uses Tomcat 5.5.20 with Java
1.6. The application's front end is designed in Flex and back end is web
servcies deployed on axis.
The application id running out of memory in about 2 days.
We are optimizing the code and fixing memory leaks . is there a way to
find out if Tomcat 5.5.20 has any inherent memory leaks. We are using J
profiler and J probe for determining the memory usage of the appliocation
during run time.

Found this JIRa issue regaring memory leaks in functional tests (Tomcat
5.5.20)
http://jira.atlassian.com/browse/JRA-12524?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel

Please let me know, if you found any memory leak issues in Tomcat 5.5.20 . I
think that 5.5.20 is a stable version of Tomcat, just wanted to know if
there are any memory issues in this version.

thank you,
Suchitha.

memory leaks (Tomcat 5.5.20 and JDK 1.6)

2007-08-10 Thread suchitha koneru

Hello Tomcat Users ,
Our  web application  uses Tomcat 5.5.20 with Java
1.6.  The application's front end is designed in Flex and back end  is web
servcies deployed on axis.
The application id running out of memory in about 2 days.
We are optimizing the code  and fixing memory leaks .  is there a way to
find out if Tomcat 5.5.20 has any inherent memory leaks.  We are using J
profiler and J probe for determining the memory usage of the appliocation
during run time.

Found this JIRa issue  regaring memory leaks in functional tests (Tomcat
5.5.20)
http://jira.atlassian.com/browse/JRA-12524?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel

Please let me know, if you found any memory leak issues in Tomcat 5.5.20 . I
think that 5.5.20 is a stable version of Tomcat, just wanted to know if
there are any memory issues in this version.

thank you,
Suchitha.

Re: memory leaks (Tomcat 5.5.20 and JDK 1.6)

2007-08-10 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Suchitha,

suchitha koneru wrote:
The application id running out of memory in about 2 days.

We are optimizing the code and fixing memory leaks . is there a way to
find out if Tomcat 5.5.20 has any inherent memory leaks.

Many people are using various Tomcat versions without any apparent
memory leaks. I would guess that either:

1. You simply need more memory to support the numbers of users you
have.
2. Your application is leaking objects or resources.

Found this JIRa issue regaring memory leaks in functional tests (Tomcat
5.5.20)
http://jira.atlassian.com/browse/JRA-12524?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel

If you read past the description of the bug, you'd see:

1. This was a bug logged against JIRA, which is a bug-tracking tool.
2. The issue was identified as a problem with JIRA and corrected.

Please let me know, if you found any memory leak issues in Tomcat 5.5.20 . I
think that 5.5.20 is a stable version of Tomcat, just wanted to know if
there are any memory issues in this version.

You should upgrade to 5.5.23 if possible, since that is the latest 5.5
version available.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGvMnM9CaO5/Lv0PARAk/1AKC55XkD04fjgfliobXpsl6W0I7RJACfaiCm
iVKULZJEn1h7Bpp89hdWFLo=
=p7FV
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: memory leaks (Tomcat 5.5.20 and JDK 1.6)

2007-08-10 Thread suchitha koneru

Thank you so Chris , I missed the part which talks about jira's memory
leak issue. Will try to increase the heap memory and detect more memory
leaks.

On 8/10/07, Christopher Schultz [EMAIL PROTECTED] wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Suchitha,

suchitha koneru wrote:
The application id running out of memory in about 2 days.

We are optimizing the code and fixing memory leaks . is there a way to
find out if Tomcat 5.5.20 has any inherent memory leaks.

Many people are using various Tomcat versions without any apparent
memory leaks. I would guess that either:

1. You simply need more memory to support the numbers of users you
have.
2. Your application is leaking objects or resources.

Found this JIRa issue regaring memory leaks in functional tests (Tomcat
5.5.20)

http://jira.atlassian.com/browse/JRA-12524?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel

If you read past the description of the bug, you'd see:

1. This was a bug logged against JIRA, which is a bug-tracking tool.
2. The issue was identified as a problem with JIRA and corrected.

Please let me know, if you found any memory leak issues in Tomcat 5.5.20. I
think that 5.5.20 is a stable version of Tomcat, just wanted to know if
there are any memory issues in this version.

You should upgrade to 5.5.23 if possible, since that is the latest 5.5
version available.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGvMnM9CaO5/Lv0PARAk/1AKC55XkD04fjgfliobXpsl6W0I7RJACfaiCm
iVKULZJEn1h7Bpp89hdWFLo=
=p7FV
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

mod_jk and memory leaks?

2006-12-11 Thread [EMAIL PROTECTED]

Has anyone experienced memory leaks in there web app
when using mod_jk?

If so, how'd you fix the leaks?
Thanks, B


 

Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk and memory leaks?

2006-12-11 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

B,

[EMAIL PROTECTED] wrote:
 Has anyone experienced memory leaks in there web app
 when using mod_jk?

What kind of leak are you observing? Something on the Apache httpd side,
or something in Tomcat? In either case, what is the (specific) behavior?

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFffa69CaO5/Lv0PARAvCGAJ4pTre4tl6DBJZvHq9vgG11HJg54QCgwBIK
Nfi5gAIww6McXg/KxGNZ70k=
=td1h
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Memory leaks on webapp redeploy

2006-11-29 Thread Mike Quilleash

I'm running on 6, I've just in the prototyping stage so using an early release 
version is fine.

I did notice that in 6 anyway (haven't looked at 5.5) that the 
releaseResources() calls this..

// Clear the classloader reference in common-logging
org.apache.juli.logging.LogFactory.release(this);

Which looks very similar to commons logging but has juli in the package 
instead.  Probably is the same thing, just under another name maybe.  Even the 
comment says common-logging.

-Original Message-
From: Rémy Maucherat [mailto:[EMAIL PROTECTED] 
Sent: 28 November 2006 23:37
To: Tomcat Users List
Subject: Re: Memory leaks on webapp redeploy

On 11/28/06, Mike Quilleash [EMAIL PROTECTED] wrote:
 As a brief aside I found the following code in the
 WebAppClassLoader.releaseResources() of Tomcat 6, so it looks like 
 some of the well-known caches are being cleared out by Tomcat itself.

Are you using 5.5 or 6.0 ? If you're using 5.5, then you should be looking at 
the 5.5 source.

At the end of the clearReferences method in 5.5, the commons-logging reference 
to the classloader is cleared again (along with other leak friendly static 
fields) so no leak can occur because of usage of logging in this method. 
Investigation has shown there was no leaking related to logging (and actually 
no reference being kept anywhere).

Rémy

-
To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



 This e-mail is bound by the terms and conditions described at 
http://www.subexazure.com/mail-disclaimer.html


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Memory leaks on webapp redeploy

 Is anyone running into issues with memory leaks occuring 
 whenever a webapp is redeployed? I've been having a lot of 
 problems with this. I think what's exacerbating the problem 
 is that I'm using Hibernate and JAX-WS which I have bundled 
 with my application which use a lot of memory.

Yes, we experience same problems with Tomcat 5.5.17 

We did a lot of tests and profiling instrumentations (Jprofiler powered) on 
many environments : Win32/Linux,  JDK1.4.2_12, JDL 1.5, Tomcat 5.5.17/5.5.20
Same problem: many redeployments (or reload) of a webapp throw an OutOfMemory 
for the PermGenspace. If you monitor your Jvm with Jvmstat tools you would see 
this non-heap memory never been released...

The problems seems to be located with Cglib classloaders referencing policy. 
There is a lot of topic on the Net, which may be interessing to read, but noone 
seems to have found a valuable solution. (Increasing the PermGenspace is NOT a 
reasonable solution)

The only way we found to fix it is to change the JVM. Indeed if we use the BEA 
Jrockit 1.4 JVM, the application can be deployed as many times you want...

Please give some news, if you find something useful

RC


 -Message d'origine-
 De : Jon Miller [mailto:[EMAIL PROTECTED] 
 Envoyé : mardi 28 novembre 2006 01:38
 À : Tomcat User List
 Objet : Memory leaks on webapp redeploy
 
 Hi all,
 
 
 I think I read in a FAQ that even using a singleton in your 
 app will cause memory leaks? Does anyone know if this is true?
 
 Jon
 
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org To 
 unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
---
Cette communication (y compris les pieces jointes) est reservee a l'usage 
exclusif du destinataire (des destinataires) et peut contenir des informations 
privilegiees, confidentielles, exemptees de divulgation selon la loi ou 
protegees par les droits d'auteur. Si vous n'etes pas un destinataire, toute 
utilisation, divulgation, distribution, reproduction, examen ou copie (totale 
ou partielle) est non-autorisee et peut etre illegale. Tout message 
electronique est susceptible d'alteration et son integrite ne peut etre 
assuree. Sanofi Pasteur decline toute responsabilite au titre de ce message 
s'il a ete modifie ou falsifie. Si vous n'etes pas destinataire de ce message, 
merci de le detruire immediatement et d'avertir l'expediteur de l'erreur de 
distribution et de la destruction du message. Merci.
This transmission (including any attachments) is intended solely for the use of 
the addressee(s) and may contain confidential information including trade 
secrets which are privileged, confidential, exempt from disclosure under 
applicable law and/or subject to copyright. If you are not an intended 
recipient, any use, disclosure, distribution, reproduction, review or copying 
(either whole or partial) is unauthorized and may be unlawful. E-mails are 
susceptible to alteration and their integrity cannot be guaranteed.Sanofi 
Pasteur shall not be liable for this e-mail if modified or falsified. If you 
are not the intended recipient of this e-mail, please delete it immediately 
from your system and notify the sender of the wrong delivery and the mail 
deletion. Thank you.
**


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Memory leaks on webapp redeploy

2006-11-28 Thread Martin Gainty

Jon-

A couple of things that may be of immediate use to you (even for older releases)
Confine your variables to have as restricted scope as possible in other words
If you have a number of JSP tags that are application scope and get by with 
request then convert those tags to use request scope
If you're using 1.. n new allocations inside of a method use gc() at the end of 
that method to force the garbage collector to recover the allocations
for profiler try http://pmd.sourceforge.net/ which will easily integrate with 
Ant or Maven builds..

Feel free to follow up with any specific questions

I hope this helps you,
Martin
This e-mail communication and any attachments may contain confidential and 
privileged information for the use of the 
designated recipients named above. If you are not the intended recipient, you 
are hereby notified that you have received
this communication in error and that any review, disclosure, dissemination, 
distribution or copying of it or its 
contents
- Original Message - 
From: Mark Thomas [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Monday, November 27, 2006 8:37 PM
Subject: Re: Memory leaks on webapp redeploy


 Jon Miller wrote:
 Hi all,
 
 Is anyone running into issues with memory leaks occuring whenever a
 webapp is redeployed?
 
 Tomcat version? There have been issues with older releases.
 
 I think I read in a FAQ that even using a singleton in your app will
 cause memory leaks? Does anyone know if this is true?
 
 It depends on how careful you are using it. There are lots of ways to
 write code that leaks memory.
 
 Rather than try guessing where the leak is, get yourself a profiler
 and find it.
 
 Mark
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: Memory leaks on webapp redeploy

2006-11-28 Thread Mikolaj Rydzewski


[EMAIL PROTECTED] wrote:

The problems seems to be located with Cglib classloaders referencing policy. 
There is a lot of topic on the Net, which may be interessing to read, but noone 
seems to have found a valuable solution. (Increasing the PermGenspace is NOT a 
reasonable solution)
  

That means, that hibernate apps will always generate OOM...

The only way we found to fix it is to change the JVM. Indeed if we use the BEA 
Jrockit 1.4 JVM, the application can be deployed as many times you want...
  

Great news! Do you know whether their JVM (1.5) is free to download and use?

--
Mikolaj Rydzewski [EMAIL PROTECTED]



smime.p7s
Description: S/MIME Cryptographic Signature

RE: Memory leaks on webapp redeploy


  The problems seems to be located with Cglib classloaders 
 referencing 
  policy. There is a lot of topic on the Net, which may be 
 interessing 
  to read, but noone seems to have found a valuable solution. 
  (Increasing the PermGenspace is NOT a reasonable solution)

 That means, that hibernate apps will always generate OOM...

Not always. But some hibernate/cglib/tomcat uses seems to generate
classloader memory leak:
http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?
pageId=2669

You can easily reproduce this behaviour.
Write a quite empty webapp with hibernate (so cglib too) which contains
just a JSP/servlet which do a dummy DBMS request (select sysdate from
dual) and print the result.
 -Deploy it 
 -access to your JSP/servlet
 -reload webapp
Write a Jmeter scenario that execute those 2 last steps.
Repeat it many times (10 times for a default heap sized JVM)
You will see your Permgenspace always growing and crash at the high
level (64MB default)


  The only way we found to fix it is to change the JVM. 
 Indeed if we use the BEA Jrockit 1.4 JVM, the application can 
 be deployed as many times you want...

 Great news! Do you know whether their JVM (1.5) is free to 
 download and use?
Yes it's free to download. For a commercial use you should check the
license.
But keep in mind, that may be a dangerous alternative. You don't know
yet what could append with Jrockit.
And the past releases don't tend to be stable as a sun one (to my
experiences)

Out solution is to install one instance of Tomcat per application :
reducing memory heap use, ...
And for each redeploy/reload we restart the tomcat service.
A Heavy but working solution 

RC

---
Cette communication (y compris les pieces jointes) est reservee a l'usage 
exclusif du destinataire (des destinataires) et peut contenir des informations 
privilegiees, confidentielles, exemptees de divulgation selon la loi ou 
protegees par les droits d'auteur. Si vous n'etes pas un destinataire, toute 
utilisation, divulgation, distribution, reproduction, examen ou copie (totale 
ou partielle) est non-autorisee et peut etre illegale. Tout message 
electronique est susceptible d'alteration et son integrite ne peut etre 
assuree. Sanofi Pasteur decline toute responsabilite au titre de ce message 
s'il a ete modifie ou falsifie. Si vous n'etes pas destinataire de ce message, 
merci de le detruire immediatement et d'avertir l'expediteur de l'erreur de 
distribution et de la destruction du message. Merci.
This transmission (including any attachments) is intended solely for the use of 
the addressee(s) and may contain confidential information including trade 
secrets which are privileged, confidential, exempt from disclosure under 
applicable law and/or subject to copyright. If you are not an intended 
recipient, any use, disclosure, distribution, reproduction, review or copying 
(either whole or partial) is unauthorized and may be unlawful. E-mails are 
susceptible to alteration and their integrity cannot be guaranteed.Sanofi 
Pasteur shall not be liable for this e-mail if modified or falsified. If you 
are not the intended recipient of this e-mail, please delete it immediately 
from your system and notify the sender of the wrong delivery and the mail 
deletion. Thank you.
**


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Memory leaks on webapp redeploy

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jon,

Jon Miller wrote:
 Is anyone running into issues with memory leaks occuring whenever a
 webapp is redeployed?

This is probably not Tomcat's fault it's Java's fault.

When Tomcat reloads a webapp, it discards the ClassLoader (or
ClassLoaders) that were being used by the old instance. These
ClassLoader objects contain information about the (duh) Classes that
were loaded during your old instance's activity.

Last time I checked, Class objects basically never get GC'd, so any
static data stays around forever. You have to shut down the VM in order
to free that memory.

This is one reason that I bounce my VM whenever I release new app
versions to production.

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFbFVj9CaO5/Lv0PARAiRrAJsFfoFlkoMPZLu9jtaaT3xvWCX8FQCeM7/k
XnEmBvVmXc8wrUWbjmnmvpA=
=xjI3
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Memory leaks on webapp redeploy

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Remy,

[EMAIL PROTECTED] wrote:
 That means, that hibernate apps will always generate OOM...
 
 Not always. But some hibernate/cglib/tomcat uses seems to generate
 classloader memory leak:
 http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?
 pageId=2669
 
 You can easily reproduce this behaviour.
 Write a quite empty webapp with hibernate (so cglib too) which contains
 just a JSP/servlet which do a dummy DBMS request (select sysdate from
 dual) and print the result.
  -Deploy it 
  -access to your JSP/servlet
  -reload webapp
 Write a Jmeter scenario that execute those 2 last steps.
 Repeat it many times (10 times for a default heap sized JVM)
 You will see your Permgenspace always growing and crash at the high
 level (64MB default)

Can you confirm the types of objects that are filling up the
Permgenspace, or just that it is filling up. I'd love to know if you're
overflowing with Class, String, and char[] objects (which are the
offenders when ClassLoaders cannot unload their Class objects).

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFbFaE9CaO5/Lv0PARAqAQAJ9FRw9jWZiNgv8WMVoHn3rbSEgqNwCdEezp
I27aI0oZuDkURlyiLPFcpLE=
=XJwy
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Memory leaks on webapp redeploy

 From: Christopher Schultz [mailto:[EMAIL PROTECTED] 
 Subject: Re: Memory leaks on webapp redeploy

 Last time I checked, Class objects basically never get GC'd,
 so any static data stays around forever. You have to shut
 down the VM in order to free that memory.

Not true - classes do get cleaned up, if there are no references to
them.  If you turn on enough GC tracing options, you can see this
happening, especially with anonymous classes, which are created and
destroyed with great frequency.  The problem is retained references to
either the associated classloader or instances of java.lang.Class; as
long as these exist, the class objects won't go away.

(The reports that JRockit doesn't run into the OOME is either a bug in
JRockit - releasing classes while there are still references to them -
or an aspect of JRockit not segregating java.lang.Class instances in a
relatively small space separate from the rest of the heap.)

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Memory leaks on webapp redeploy

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

Caldarale, Charles R wrote:
 From: Christopher Schultz [mailto:[EMAIL PROTECTED] 
 Subject: Re: Memory leaks on webapp redeploy

 Last time I checked, Class objects basically never get GC'd,
 so any static data stays around forever. You have to shut
 down the VM in order to free that memory.

 Not true - classes do get cleaned up, if there are no references to
 them.

This wasn't the case some time ago. A cleanly written webapp would
double the number of Class objects kept around after a re-deploy
(actually, after an automatic re-deploy, but that shouldn't have mattered).

It's been a while since I profiled any of my apps, but that used to be
the case... after a few days in development of auto-re-loading the
webapps, we'd get an OOM. We could watch the heap fill up with useless
Class objects (for instance, my.package.Class showed up 10 times after 9
restarts, and we don't do anything crazy like keeping Class references
around, singletons, thread locals variables, static class data, etc.).

The only thing I can think of is perhaps Java is keeping introspection
information around and never releasing it. If that's the case, it looks
like a call to java.beans.Introspector.flushCaches() would have fixed my
problem.

I'll look into this, if I can figure out how to get my copy of
OptimizeIt working again. Wow. I really need to get a profiler that was
written in the new millennium, eh?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFbFpE9CaO5/Lv0PARArqaAKC3PG1uOU8MbghsntHZxNvaHS1cvgCggJAr
2x6LO1cKa73h9FwdBBBL9mI=
=d4hC
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Memory leaks on webapp redeploy

 From: Christopher Schultz [mailto:[EMAIL PROTECTED] 
 Subject: Re: Memory leaks on webapp redeploy

 This wasn't the case some time ago. A cleanly written webapp would
 double the number of Class objects kept around after a re-deploy
 (actually, after an automatic re-deploy, but that shouldn't 
 have mattered).

I was referring to the generic nature of your statement, not the
specifics of running within Tomcat.

 The only thing I can think of is perhaps Java is keeping introspection
 information around and never releasing it.

Quite possible.  There's a good discussion of the issue here:
http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?
pageId=2669

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Memory leaks on webapp redeploy


 It's been a while since I profiled any of my apps, but that 
 used to be the case... after a few days in development of 
 auto-re-loading the webapps, we'd get an OOM. We could watch 
 the heap fill up with useless Class objects (for instance, 
 my.package.Class showed up 10 times after 9 restarts, and we 
 don't do anything crazy like keeping Class references around, 
 singletons, thread locals variables, static class data, etc.).

Same problem here. Reloading such a tiny webapp generates memory leaks
in the PermGenSpace (which is a non-heap space).
Some libraries (apparently cglib) kept some Classloaders references and
don't free them. This leads to an OOM : Out of PermgenSpace after some
reloads (or redeploy)
We have try to setup a cleaner ServletContextListener to force some
cleaning job (Introspector caches) on contextDestroyed event, but it
doesn't give any more results.

Profiling instrumentations gave us some informations about what is
loaded. But it's quite difficult to find the guilty source.

I'm very interested in the following of this issue.

RC

---
Cette communication (y compris les pieces jointes) est reservee a l'usage 
exclusif du destinataire (des destinataires) et peut contenir des informations 
privilegiees, confidentielles, exemptees de divulgation selon la loi ou 
protegees par les droits d'auteur. Si vous n'etes pas un destinataire, toute 
utilisation, divulgation, distribution, reproduction, examen ou copie (totale 
ou partielle) est non-autorisee et peut etre illegale. Tout message 
electronique est susceptible d'alteration et son integrite ne peut etre 
assuree. Sanofi Pasteur decline toute responsabilite au titre de ce message 
s'il a ete modifie ou falsifie. Si vous n'etes pas destinataire de ce message, 
merci de le detruire immediatement et d'avertir l'expediteur de l'erreur de 
distribution et de la destruction du message. Merci.
This transmission (including any attachments) is intended solely for the use of 
the addressee(s) and may contain confidential information including trade 
secrets which are privileged, confidential, exempt from disclosure under 
applicable law and/or subject to copyright. If you are not an intended 
recipient, any use, disclosure, distribution, reproduction, review or copying 
(either whole or partial) is unauthorized and may be unlawful. E-mails are 
susceptible to alteration and their integrity cannot be guaranteed.Sanofi 
Pasteur shall not be liable for this e-mail if modified or falsified. If you 
are not the intended recipient of this e-mail, please delete it immediately 
from your system and notify the sender of the wrong delivery and the mail 
deletion. Thank you.
**


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Memory leaks on webapp redeploy

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

Caldarale, Charles R wrote:
 Subject: Re: Memory leaks on webapp redeploy

 The only thing I can think of is perhaps Java is keeping introspection
 information around and never releasing it.
 
 Quite possible.  There's a good discussion of the issue here:
 http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?
 pageId=2669

Yup; that's where I read about the Introspector.flushCaches trick. I use
Velocity, not JSP, and I just checked the source code for their
introspection code, and it does not appear to use the built-in Java
Introspector, so that's unlikely to be the problem. Velocity is the only
place that we use any introspection at all, so I'll be interested to see
the results of profiling especially which objects are holding on to
references to old Class objects.

Maybe this issue has been fixed in recent VMs (IIRC, older VMs -- maybe
1.3-era -- would never discard java.lang.Class objects. Java 1.5 has the
-Xnoclassgc option, which might exist to replicate this feature for
apps which relied on Class objects living forever.

For instance, if you had a singleton with a static instance of the
class, but no references to the Class object, no instances other than
the singleton (a reasonable assumption for a singleton), and no outside
references to the singleton object, then the VM is within it's rights to
discard both the instance and the Class since they are unused. I seem
to recall this being a problem for folks who thought that singletons
were a good idea, and so the Java folks decided to keep Class objects
around forever.

Perhaps that changed. Anyone know about the history of this phenomenon?
Or am I just crazy and making the whole thing up? ;)

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFbGTL9CaO5/Lv0PARAt2yAKCDRa6Mx0ojhSdyHfYmZkKLoVL6hACgikgU
USkA4X4E2DIy9vk/Qwxs5d0=
=/sNx
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Memory leaks on webapp redeploy

 From: Christopher Schultz [mailto:[EMAIL PROTECTED] 
 Subject: Re: Memory leaks on webapp redeploy

 Maybe this issue has been fixed in recent VMs (IIRC, older 
 VMs -- maybe 1.3-era -- would never discard java.lang.Class
 objects.

Not true either.  I've been porting Sun's JVMs to various platforms
since 1.2, and GC of classes has always been available (not sure about
1.1).

 Java 1.5 has the -Xnoclassgc option

That's also been around since at least 1.3.

 For instance, if you had a singleton with a static instance of the
 class, but no references to the Class object, no instances other than
 the singleton (a reasonable assumption for a singleton), and 
 no outside references to the singleton object, then the VM is within 
 it's rights to discard both the instance and the Class since they are 
 unused. I seem to recall this being a problem for folks who thought
 that singletons were a good idea, and so the Java folks decided to
keep
 Class objects around forever.

The first part is true, the latter conclusion isn't, at least not in
Sun-based JVMs.  You do have to be careful if only reflection is used to
access a class, since it can disappear as you described.

 Or am I just crazy and making the whole thing up? ;)

Always a possibility, especially in this business :-)

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Memory leaks on webapp redeploy



http://wiki.apache.org/tomcat/OutOfMemory : Another link which deals
about OOM and singleton.

Have you ever tried to do some inspections with decent profiler
(OptimiseIt, Jprofiler, Yourkit, ...) ?

RC
---
Cette communication (y compris les pieces jointes) est reservee a l'usage 
exclusif du destinataire (des destinataires) et peut contenir des informations 
privilegiees, confidentielles, exemptees de divulgation selon la loi ou 
protegees par les droits d'auteur. Si vous n'etes pas un destinataire, toute 
utilisation, divulgation, distribution, reproduction, examen ou copie (totale 
ou partielle) est non-autorisee et peut etre illegale. Tout message 
electronique est susceptible d'alteration et son integrite ne peut etre 
assuree. Sanofi Pasteur decline toute responsabilite au titre de ce message 
s'il a ete modifie ou falsifie. Si vous n'etes pas destinataire de ce message, 
merci de le detruire immediatement et d'avertir l'expediteur de l'erreur de 
distribution et de la destruction du message. Merci.
This transmission (including any attachments) is intended solely for the use of 
the addressee(s) and may contain confidential information including trade 
secrets which are privileged, confidential, exempt from disclosure under 
applicable law and/or subject to copyright. If you are not an intended 
recipient, any use, disclosure, distribution, reproduction, review or copying 
(either whole or partial) is unauthorized and may be unlawful. E-mails are 
susceptible to alteration and their integrity cannot be guaranteed.Sanofi 
Pasteur shall not be liable for this e-mail if modified or falsified. If you 
are not the intended recipient of this e-mail, please delete it immediately 
from your system and notify the sender of the wrong delivery and the mail 
deletion. Thank you.
**


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Memory leaks on webapp redeploy

Currently I'm using 5.5.17, but, it's happened with every other version that 
I've used for the past several years as well.

Jon

- Original Message - 
From: Mark Thomas [EMAIL PROTECTED]

To: Tomcat Users List users@tomcat.apache.org
Sent: Monday, November 27, 2006 7:37 PM
Subject: Re: Memory leaks on webapp redeploy

Jon Miller wrote:

Hi all,

Is anyone running into issues with memory leaks occuring whenever a
webapp is redeployed?

Tomcat version? There have been issues with older releases.

I think I read in a FAQ that even using a singleton in your app will
cause memory leaks? Does anyone know if this is true?

It depends on how careful you are using it. There are lots of ways to
write code that leaks memory.

Rather than try guessing where the leak is, get yourself a profiler
and find it.

Mark

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Memory leaks on webapp redeploy

I'm getting ready to try NetBeans profiler right now. I tried it awhile back 
before it was released, but, there was something wrong with the Solaris 
library, so, I couldn't get it to work. I'm hoping I'll have better luck now 
that it's been released officially.


Jon

- Original Message - 
From: anjan bacchu [EMAIL PROTECTED]

To: Tomcat Users List users@tomcat.apache.org
Sent: Monday, November 27, 2006 8:08 PM
Subject: Re: Memory leaks on webapp redeploy



Hi Mark,

 Does anyone on the tomcat dev list use Netbeans profiler at all ? OR do
you guys
exclusively use YourKit ?

Thank you,

BR,
~A

On 11/27/06, Mark Thomas [EMAIL PROTECTED] wrote:


Jon Miller wrote:
 Hi all,

 Is anyone running into issues with memory leaks occuring whenever a
 webapp is redeployed?

Tomcat version? There have been issues with older releases.

 I think I read in a FAQ that even using a singleton in your app will
 cause memory leaks? Does anyone know if this is true?

It depends on how careful you are using it. There are lots of ways to
write code that leaks memory.

Rather than try guessing where the leak is, get yourself a profiler
and find it.

Mark

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
BR,
Anjan Bacchu
Summit Information Systems




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Memory leaks on webapp redeploy

Thanks for the info Remy. I've been using Sun's JVM, but, I think I'm going 
to try IBM's to see if that makes a difference.

Jon

- Original Message - 
From: [EMAIL PROTECTED]

To: users@tomcat.apache.org
Sent: Tuesday, November 28, 2006 3:30 AM
Subject: RE: Memory leaks on webapp redeploy

Is anyone running into issues with memory leaks occuring
whenever a webapp is redeployed? I've been having a lot of
problems with this. I think what's exacerbating the problem
is that I'm using Hibernate and JAX-WS which I have bundled
with my application which use a lot of memory.

Yes, we experience same problems with Tomcat 5.5.17

We did a lot of tests and profiling instrumentations (Jprofiler powered) 
on many environments : Win32/Linux,  JDK1.4.2_12, JDL 1.5, Tomcat 
5.5.17/5.5.20
Same problem: many redeployments (or reload) of a webapp throw an 
OutOfMemory for the PermGenspace. If you monitor your Jvm with Jvmstat 
tools you would see this non-heap memory never been released...

The problems seems to be located with Cglib classloaders referencing 
policy. There is a lot of topic on the Net, which may be interessing to 
read, but noone seems to have found a valuable solution. (Increasing the 
PermGenspace is NOT a reasonable solution)

The only way we found to fix it is to change the JVM. Indeed if we use the 
BEA Jrockit 1.4 JVM, the application can be deployed as many times you 
want...

Please give some news, if you find something useful

RC

-Message d'origine-
De : Jon Miller [mailto:[EMAIL PROTECTED]
Envoyé : mardi 28 novembre 2006 01:38
À : Tomcat User List
Objet : Memory leaks on webapp redeploy

Hi all,

I think I read in a FAQ that even using a singleton in your
app will cause memory leaks? Does anyone know if this is true?

Jon

-
To start a new topic, e-mail: users@tomcat.apache.org To
unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---
Cette communication (y compris les pieces jointes) est reservee a l'usage 
exclusif du destinataire (des destinataires) et peut contenir des 
informations privilegiees, confidentielles, exemptees de divulgation selon 
la loi ou protegees par les droits d'auteur. Si vous n'etes pas un 
destinataire, toute utilisation, divulgation, distribution, reproduction, 
examen ou copie (totale ou partielle) est non-autorisee et peut etre 
illegale. Tout message electronique est susceptible d'alteration et son 
integrite ne peut etre assuree. Sanofi Pasteur decline toute 
responsabilite au titre de ce message s'il a ete modifie ou falsifie. Si 
vous n'etes pas destinataire de ce message, merci de le detruire 
immediatement et d'avertir l'expediteur de l'erreur de distribution et de 
la destruction du message. Merci.
This transmission (including any attachments) is intended solely for the 
use of the addressee(s) and may contain confidential information including 
trade secrets which are privileged, confidential, exempt from disclosure 
under applicable law and/or subject to copyright. If you are not an 
intended recipient, any use, disclosure, distribution, reproduction, 
review or copying (either whole or partial) is unauthorized and may be 
unlawful. E-mails are susceptible to alteration and their integrity cannot 
be guaranteed.Sanofi Pasteur shall not be liable for this e-mail if 
modified or falsified. If you are not the intended recipient of this 
e-mail, please delete it immediately from your system and notify the 
sender of the wrong delivery and the mail deletion. Thank you.

**

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Memory leaks on webapp redeploy

2006-11-28 Thread Mike Quilleash

 2006 16:43
To: Tomcat Users List
Subject: RE: Memory leaks on webapp redeploy

 From: Christopher Schultz [mailto:[EMAIL PROTECTED]
 Subject: Re: Memory leaks on webapp redeploy

 Maybe this issue has been fixed in recent VMs (IIRC, older VMs -- 
 maybe 1.3-era -- would never discard java.lang.Class objects.

Not true either.  I've been porting Sun's JVMs to various platforms
since 1.2, and GC of classes has always been available (not sure about
1.1).

 Java 1.5 has the -Xnoclassgc option

That's also been around since at least 1.3.

 For instance, if you had a singleton with a static instance of the 
 class, but no references to the Class object, no instances other than 
 the singleton (a reasonable assumption for a singleton), and no 
 outside references to the singleton object, then the VM is within it's

 rights to discard both the instance and the Class since they are 
 unused. I seem to recall this being a problem for folks who thought 
 that singletons were a good idea, and so the Java folks decided to
keep
 Class objects around forever.

The first part is true, the latter conclusion isn't, at least not in
Sun-based JVMs.  You do have to be careful if only reflection is used to
access a class, since it can disappear as you described.

 Or am I just crazy and making the whole thing up? ;)

Always a possibility, especially in this business :-)

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 This e-mail is bound by the terms and conditions described at 
http://www.subexazure.com/mail-disclaimer.html

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Memory leaks on webapp redeploy

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jon,

Jon Miller wrote:
 I'm getting ready to try NetBeans profiler right now. I tried it awhile
 back before it was released, but, there was something wrong with the
 Solaris library, so, I couldn't get it to work. I'm hoping I'll have
 better luck now that it's been released officially.

I downloaded the Linux version of JProbe's profiler, and I can't figure
out how to start it. The only binary that makes any sense is
jpprofiler, and that gives me a DISPLAY is inaccessible error, even
though I can run xterm and xclock and stuff no problem. :(

Let me know how it goes with the NetBeans profiler. Also, let me know if
it was easy to get going. I'd love to use something that I can attach to
a running process -- sorta like Sun's jconsole.

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFbHXp9CaO5/Lv0PARAot6AJ4rVIkv4lKHpDXm18gzCQky4FBOgACfa+Hl
alSevcwHO7SLhpblRcOKm8I=
=DVpu
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Memory leaks on webapp redeploy

 From: Mike Quilleash [mailto:[EMAIL PROTECTED] 
 Subject: RE: Memory leaks on webapp redeploy

 Looks like during the WebappClassLoader cleanup the logging is being
 reinitialised.

You may well have found the problem.  Must be some context-specific
logging going on after contextDestroyed() is called.  What happens if
you put a call to LogFactory.releaseAll() in contextInitialized() rather
than contextDestroyed()?  This should remove all traces of the prior
instance.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Memory leaks on webapp redeploy