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 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
