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