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 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 Grails app that I routinely use to test database
> issues. It just uses the JNDI connection specified to do some basic
> database crud.
>
>
> >Did you use H2?
>
> Yes. h2-1.3.161.jar
>
>
> >Because I don't get these errors in catalina.out intermittently but
> >always.
>
> No errors in any of my log files. I tested stopping the Tomcat
> instance, restarting it and undeploying the application.
>
> Dan
>
>
>
> >
> > Thank you
> >
> >
> >
> >
> >
> >
> > From: Daniel Mikusa <dmik...@vmware.com>
> > To: Hermes Flying <flyingher...@yahoo.com>
> > Sent: Wednesday, April 4, 2012 4:25 PM
> > Subject: Re: Discrepancy between Tomcat's connection pool and
> > tomcat's report on memory leaks
> >
> > ----- Original Message -----
> > >
> > >
> > > 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?
> > >
> > >
> >
> > Seems a little weird. The message is indicating that the threads
> > which have not stopped reside in the application
> > "[/GeneralApplication]". This would seem to imply that the
> > connection pool was created by the application. The configuration
> > that you've specified here would have the container creating the
> > connection pool, which shouldn't trigger messages like this.
> >
> > Are you sure your application is not creating a connection pool?
> >
> > As a side note, I tried the configuration you mentioned in a local
> > Tomcat instance and it worked fine, no errors.
> >
> > Dan
> >
> >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 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
> > >
> > >
> > >
> > >
> >
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
