Thread: [c3p0-users] Running out of connections?
Status: Beta
Brought to you by:
swaldman
From: Aaron Z. <aa...@vt...> - 2008-11-06 16:41:49
|
I am running out of connections with a ComboPooledDataSource and I need some tips on figuring out why. I have these settings for testing: cpds.setAutoCommitOnClose(false); cpds.setAcquireIncrement(1); cpds.setMinPoolSize(1); cpds.setInitialPoolSize(1); cpds.setMaxPoolSize(1); // might need to comment these out for debugging cpds.setUnreturnedConnectionTimeout(10); cpds.setDebugUnreturnedConnectionStackTraces(true); In my code I am explicitly calling close on my connections everywhere as far as I can tell but I still run out of connections while running my test cases. If I increase the max connections then I get further through the tests before running out but I am sure this is an indication of problems. I am including the stacktrace which appears when the connections run out below if it helps. I am open to any possible suggestions. :-) -AZ INFO Logging the stack trace by which the overdue resource was checked-out. [2008-11-06 16:39:58,812] (BasicResourcePool.java:1395) java.lang.Exception: DEBUG ONLY: Overdue resource check-out stack trace. at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:506) at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525) at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128) at org.dspace.database.DSpaceDataSource.getConnection(DSpaceDataSource.java:212) at org.sakaiproject.genericdao.springjdbc.SmartDataSourceWrapper.getConnection(SmartDataSourceWrapper.java:53) at org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getNewConnection(ThreadboundConnectionsDataSourceWrapper.java:114) at org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.createBindWrapConnection(ThreadboundConnectionsDataSourceWrapper.java:91) at org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getConnection(ThreadboundConnectionsDataSourceWrapper.java:133) at org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getConnection(ThreadboundConnectionsDataSourceWrapper.java:126) at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:113) at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:79) at org.springframework.jdbc.core.support.JdbcDaoSupport.getConnection(JdbcDaoSupport.java:132) at org.sakaiproject.genericdao.springjdbc.JdbcGenericDao.commitTransaction(JdbcGenericDao.java:1057) at org.dspace.services.user.UserDAOTest.initDB(UserDAOTest.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.ClassRoadie.runBefores(ClassRoadie.java:49) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:36) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) INFO Destroying connection (2rvxw07xvtfzzt13e7k5w|d47c65): org.apache.derby.impl.jdbc.EmbedConnection30@10970704 (XID = 144), (SESSIONID = 1), (DATABASE = DSpaceDerby), (DRDAID = null) [2008-11-06 16:39:58,815] (DSpace TestingConnectionCustomizer.java:41) -- Aaron Zeckoski (aa...@vt...) Senior Research Engineer - CARET - Cambridge University [http://bugs.sakaiproject.org/confluence/display/~aaronz/] Sakai Fellow - [http://aaronz-sakai.blogspot.com/] |
From: Aaron Z. <aa...@vt...> - 2008-11-06 17:06:51
|
Then my tests get a little further before running out. It still does not solve the underlyig issue though. Note that this is for testing (i.e. running programmatic tests) only. -AZ On Thu, Nov 6, 2008 at 5:02 PM, Adrian Woodhead <ad...@la...> wrote: > cpds.setMaxPoolSize(1); > > > Doesn't creating a pool of size 1 defeat the point of using a connection > pool? What if you increase that to something like 10? > > Aaron Zeckoski wrote: >> >> I am running out of connections with a ComboPooledDataSource and I >> need some tips on figuring out why. >> I have these settings for testing: >> cpds.setAutoCommitOnClose(false); >> cpds.setAcquireIncrement(1); >> cpds.setMinPoolSize(1); >> cpds.setInitialPoolSize(1); >> cpds.setMaxPoolSize(1); >> // might need to comment these out for debugging >> cpds.setUnreturnedConnectionTimeout(10); >> cpds.setDebugUnreturnedConnectionStackTraces(true); >> >> In my code I am explicitly calling close on my connections everywhere >> as far as I can tell but I still run out of connections while running >> my test cases. If I increase the max connections then I get further >> through the tests before running out but I am sure this is an >> indication of problems. >> I am including the stacktrace which appears when the connections run >> out below if it helps. >> >> I am open to any possible suggestions. >> :-) >> -AZ >> >> INFO Logging the stack trace by which the overdue resource was >> checked-out. [2008-11-06 16:39:58,812] (BasicResourcePool.java:1395) >> java.lang.Exception: DEBUG ONLY: Overdue resource check-out stack trace. >> at >> com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:506) >> at >> com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525) >> at >> com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128) >> at >> org.dspace.database.DSpaceDataSource.getConnection(DSpaceDataSource.java:212) >> at >> org.sakaiproject.genericdao.springjdbc.SmartDataSourceWrapper.getConnection(SmartDataSourceWrapper.java:53) >> at >> org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getNewConnection(ThreadboundConnectionsDataSourceWrapper.java:114) >> at >> org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.createBindWrapConnection(ThreadboundConnectionsDataSourceWrapper.java:91) >> at >> org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getConnection(ThreadboundConnectionsDataSourceWrapper.java:133) >> at >> org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getConnection(ThreadboundConnectionsDataSourceWrapper.java:126) >> at >> org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:113) >> at >> org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:79) >> at >> org.springframework.jdbc.core.support.JdbcDaoSupport.getConnection(JdbcDaoSupport.java:132) >> at >> org.sakaiproject.genericdao.springjdbc.JdbcGenericDao.commitTransaction(JdbcGenericDao.java:1057) >> at org.dspace.services.user.UserDAOTest.initDB(UserDAOTest.java:54) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:585) >> at >> org.junit.internal.runners.ClassRoadie.runBefores(ClassRoadie.java:49) >> at >> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:36) >> at >> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) >> at >> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) >> at >> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) >> INFO Destroying connection (2rvxw07xvtfzzt13e7k5w|d47c65): >> org.apache.derby.impl.jdbc.EmbedConnection30@10970704 (XID = 144), >> (SESSIONID = 1), (DATABASE = DSpaceDerby), (DRDAID = null) >> [2008-11-06 16:39:58,815] (DSpace >> TestingConnectionCustomizer.java:41) >> >> > -- Aaron Zeckoski (aa...@vt...) Senior Research Engineer - CARET - Cambridge University [http://bugs.sakaiproject.org/confluence/display/~aaronz/] Sakai Fellow - [http://aaronz-sakai.blogspot.com/] |
From: Steve W. <swa...@mc...> - 2008-11-06 17:53:24
|
The stack trace shown is the code that's leaking Connections. Whatever's acquiring Connections through that stack trace is failing to close() them. Look at where you think you are close()ing these Connections, and be sure there is no codepath that could avoid the close(). That is, the close() should be in a finally where the getConnection() call is in an associated try, and there should be no way that the finally block could exit (for example, on an earlier Exception) without close() being called. smiles, Steve On Nov 6, 2008, at 12:06 PM, Aaron Zeckoski wrote: > Then my tests get a little further before running out. > It still does not solve the underlyig issue though. > Note that this is for testing (i.e. running programmatic tests) only. > -AZ > > > On Thu, Nov 6, 2008 at 5:02 PM, Adrian Woodhead <ad...@la...> > wrote: >> cpds.setMaxPoolSize(1); >> >> >> Doesn't creating a pool of size 1 defeat the point of using a >> connection >> pool? What if you increase that to something like 10? >> >> Aaron Zeckoski wrote: >>> >>> I am running out of connections with a ComboPooledDataSource and I >>> need some tips on figuring out why. >>> I have these settings for testing: >>> cpds.setAutoCommitOnClose(false); >>> cpds.setAcquireIncrement(1); >>> cpds.setMinPoolSize(1); >>> cpds.setInitialPoolSize(1); >>> cpds.setMaxPoolSize(1); >>> // might need to comment these out for debugging >>> cpds.setUnreturnedConnectionTimeout(10); >>> cpds.setDebugUnreturnedConnectionStackTraces(true); >>> >>> In my code I am explicitly calling close on my connections >>> everywhere >>> as far as I can tell but I still run out of connections while >>> running >>> my test cases. If I increase the max connections then I get further >>> through the tests before running out but I am sure this is an >>> indication of problems. >>> I am including the stacktrace which appears when the connections run >>> out below if it helps. >>> >>> I am open to any possible suggestions. >>> :-) >>> -AZ >>> >>> INFO Logging the stack trace by which the overdue resource was >>> checked-out. [2008-11-06 16:39:58,812] (BasicResourcePool.java: >>> 1395) >>> java.lang.Exception: DEBUG ONLY: Overdue resource check-out stack >>> trace. >>> at >>> com >>> .mchange >>> .v2 >>> .resourcepool >>> .BasicResourcePool.checkoutResource(BasicResourcePool.java:506) >>> at >>> com >>> .mchange >>> .v2 >>> .c3p0 >>> .impl >>> .C3P0PooledConnectionPool >>> .checkoutPooledConnection(C3P0PooledConnectionPool.java:525) >>> at >>> com >>> .mchange >>> .v2 >>> .c3p0 >>> .impl >>> .AbstractPoolBackedDataSource >>> .getConnection(AbstractPoolBackedDataSource.java:128) >>> at >>> org >>> .dspace >>> .database.DSpaceDataSource.getConnection(DSpaceDataSource.java:212) >>> at >>> org >>> .sakaiproject >>> .genericdao >>> .springjdbc >>> .SmartDataSourceWrapper.getConnection(SmartDataSourceWrapper.java: >>> 53) >>> at >>> org >>> .sakaiproject >>> .genericdao >>> .springjdbc >>> .ThreadboundConnectionsDataSourceWrapper >>> .getNewConnection(ThreadboundConnectionsDataSourceWrapper.java:114) >>> at >>> org >>> .sakaiproject >>> .genericdao >>> .springjdbc >>> .ThreadboundConnectionsDataSourceWrapper >>> .createBindWrapConnection >>> (ThreadboundConnectionsDataSourceWrapper.java:91) >>> at >>> org >>> .sakaiproject >>> .genericdao >>> .springjdbc >>> .ThreadboundConnectionsDataSourceWrapper >>> .getConnection(ThreadboundConnectionsDataSourceWrapper.java:133) >>> at >>> org >>> .sakaiproject >>> .genericdao >>> .springjdbc >>> .ThreadboundConnectionsDataSourceWrapper >>> .getConnection(ThreadboundConnectionsDataSourceWrapper.java:126) >>> at >>> org >>> .springframework >>> .jdbc >>> .datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java: >>> 113) >>> at >>> org >>> .springframework >>> .jdbc >>> .datasource.DataSourceUtils.getConnection(DataSourceUtils.java:79) >>> at >>> org >>> .springframework >>> .jdbc >>> .core.support.JdbcDaoSupport.getConnection(JdbcDaoSupport.java:132) >>> at >>> org >>> .sakaiproject >>> .genericdao >>> .springjdbc.JdbcGenericDao.commitTransaction(JdbcGenericDao.java: >>> 1057) >>> at >>> org.dspace.services.user.UserDAOTest.initDB(UserDAOTest.java:54) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun >>> .reflect >>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>> at >>> sun >>> .reflect >>> .DelegatingMethodAccessorImpl >>> .invoke(DelegatingMethodAccessorImpl.java:25) >>> at java.lang.reflect.Method.invoke(Method.java:585) >>> at >>> org.junit.internal.runners.ClassRoadie.runBefores(ClassRoadie.java: >>> 49) >>> at >>> org >>> .junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java: >>> 36) >>> at >>> org >>> .junit >>> .internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) >>> at >>> org >>> .eclipse >>> .jdt >>> .internal >>> .junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) >>> at >>> org >>> .eclipse >>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) >>> at >>> org >>> .eclipse >>> .jdt >>> .internal >>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) >>> at >>> org >>> .eclipse >>> .jdt >>> .internal >>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) >>> at >>> org >>> .eclipse >>> .jdt >>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java: >>> 386) >>> at >>> org >>> .eclipse >>> .jdt >>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java: >>> 196) >>> INFO Destroying connection (2rvxw07xvtfzzt13e7k5w|d47c65): >>> org.apache.derby.impl.jdbc.EmbedConnection30@10970704 (XID = 144), >>> (SESSIONID = 1), (DATABASE = DSpaceDerby), (DRDAID = null) >>> [2008-11-06 16:39:58,815] (DSpace >>> TestingConnectionCustomizer.java:41) >>> >>> >> > > > > -- > Aaron Zeckoski (aa...@vt...) > Senior Research Engineer - CARET - Cambridge University > [http://bugs.sakaiproject.org/confluence/display/~aaronz/] > Sakai Fellow - [http://aaronz-sakai.blogspot.com/] > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > c3p0-users mailing list > c3p...@li... > https://lists.sourceforge.net/lists/listinfo/c3p0-users ~oo~ Steve Waldman swa...@mc... |
From: Aaron Z. <aa...@vt...> - 2008-11-06 17:27:28
|
Sorry to be dense, can you elaborate on this statement? "The stack trace shown is the code that's leaking Connections." Are you saying that something in that chain is not closing up the connections (the end of the chain is C3P0 so it seems that the thing responsible would be it in this case) or that something previously did not close the connection and this stacktrace is what occurs when it attempts to get the new connection but cannot? Also, if the connection is closed but the connection object is being held onto somewhere would this stop C3P0 from being able to give me another one or does it just abandon the object and create new ones? -AZ On Thu, Nov 6, 2008 at 5:17 PM, Steve Waldman <swa...@mc...> wrote: > The stack trace shown is the code that's leaking Connections. Whatever's > acquiring Connections through that stack trace is failing to close() them. > Look at where you think you are close()ing these Connections, and be sure > there is no codepath that could avoid the close(). That is, the close() > should be in a finally where the getConnection() call is in an associated > try, and there should be no way that the finally block could exit (for > example, on an earlier Exception) without close() being called. > > smiles, > Steve > > > On Nov 6, 2008, at 12:06 PM, Aaron Zeckoski wrote: > >> Then my tests get a little further before running out. >> It still does not solve the underlyig issue though. >> Note that this is for testing (i.e. running programmatic tests) only. >> -AZ >> >> >> On Thu, Nov 6, 2008 at 5:02 PM, Adrian Woodhead <ad...@la...> wrote: >>> >>> cpds.setMaxPoolSize(1); >>> >>> >>> Doesn't creating a pool of size 1 defeat the point of using a connection >>> pool? What if you increase that to something like 10? >>> >>> Aaron Zeckoski wrote: >>>> >>>> I am running out of connections with a ComboPooledDataSource and I >>>> need some tips on figuring out why. >>>> I have these settings for testing: >>>> cpds.setAutoCommitOnClose(false); >>>> cpds.setAcquireIncrement(1); >>>> cpds.setMinPoolSize(1); >>>> cpds.setInitialPoolSize(1); >>>> cpds.setMaxPoolSize(1); >>>> // might need to comment these out for debugging >>>> cpds.setUnreturnedConnectionTimeout(10); >>>> cpds.setDebugUnreturnedConnectionStackTraces(true); >>>> >>>> In my code I am explicitly calling close on my connections everywhere >>>> as far as I can tell but I still run out of connections while running >>>> my test cases. If I increase the max connections then I get further >>>> through the tests before running out but I am sure this is an >>>> indication of problems. >>>> I am including the stacktrace which appears when the connections run >>>> out below if it helps. >>>> >>>> I am open to any possible suggestions. >>>> :-) >>>> -AZ >>>> >>>> INFO Logging the stack trace by which the overdue resource was >>>> checked-out. [2008-11-06 16:39:58,812] (BasicResourcePool.java:1395) >>>> java.lang.Exception: DEBUG ONLY: Overdue resource check-out stack trace. >>>> at >>>> >>>> com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:506) >>>> at >>>> >>>> com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525) >>>> at >>>> >>>> com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128) >>>> at >>>> >>>> org.dspace.database.DSpaceDataSource.getConnection(DSpaceDataSource.java:212) >>>> at >>>> >>>> org.sakaiproject.genericdao.springjdbc.SmartDataSourceWrapper.getConnection(SmartDataSourceWrapper.java:53) >>>> at >>>> >>>> org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getNewConnection(ThreadboundConnectionsDataSourceWrapper.java:114) >>>> at >>>> >>>> org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.createBindWrapConnection(ThreadboundConnectionsDataSourceWrapper.java:91) >>>> at >>>> >>>> org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getConnection(ThreadboundConnectionsDataSourceWrapper.java:133) >>>> at >>>> >>>> org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getConnection(ThreadboundConnectionsDataSourceWrapper.java:126) >>>> at >>>> >>>> org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:113) >>>> at >>>> >>>> org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:79) >>>> at >>>> >>>> org.springframework.jdbc.core.support.JdbcDaoSupport.getConnection(JdbcDaoSupport.java:132) >>>> at >>>> >>>> org.sakaiproject.genericdao.springjdbc.JdbcGenericDao.commitTransaction(JdbcGenericDao.java:1057) >>>> at org.dspace.services.user.UserDAOTest.initDB(UserDAOTest.java:54) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at >>>> >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>>> at >>>> >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>>> at java.lang.reflect.Method.invoke(Method.java:585) >>>> at >>>> org.junit.internal.runners.ClassRoadie.runBefores(ClassRoadie.java:49) >>>> at >>>> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:36) >>>> at >>>> >>>> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) >>>> at >>>> >>>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) >>>> at >>>> >>>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) >>>> at >>>> >>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) >>>> at >>>> >>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) >>>> at >>>> >>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) >>>> at >>>> >>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) >>>> INFO Destroying connection (2rvxw07xvtfzzt13e7k5w|d47c65): >>>> org.apache.derby.impl.jdbc.EmbedConnection30@10970704 (XID = 144), >>>> (SESSIONID = 1), (DATABASE = DSpaceDerby), (DRDAID = null) >>>> [2008-11-06 16:39:58,815] (DSpace >>>> TestingConnectionCustomizer.java:41) >>>> >>>> >>> >> >> >> >> -- >> Aaron Zeckoski (aa...@vt...) >> Senior Research Engineer - CARET - Cambridge University >> [http://bugs.sakaiproject.org/confluence/display/~aaronz/] >> Sakai Fellow - [http://aaronz-sakai.blogspot.com/] >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> c3p0-users mailing list >> c3p...@li... >> https://lists.sourceforge.net/lists/listinfo/c3p0-users > > ~oo~ > Steve Waldman > swa...@mc... > > > > -- Aaron Zeckoski (aa...@vt...) Senior Research Engineer - CARET - Cambridge University [http://bugs.sakaiproject.org/confluence/display/~aaronz/] Sakai Fellow - [http://aaronz-sakai.blogspot.com/] |
From: Adrian W. <ad...@la...> - 2008-11-06 17:29:07
|
cpds.setMaxPoolSize(1); Doesn't creating a pool of size 1 defeat the point of using a connection pool? What if you increase that to something like 10? Aaron Zeckoski wrote: > I am running out of connections with a ComboPooledDataSource and I > need some tips on figuring out why. > I have these settings for testing: > cpds.setAutoCommitOnClose(false); > cpds.setAcquireIncrement(1); > cpds.setMinPoolSize(1); > cpds.setInitialPoolSize(1); > cpds.setMaxPoolSize(1); > // might need to comment these out for debugging > cpds.setUnreturnedConnectionTimeout(10); > cpds.setDebugUnreturnedConnectionStackTraces(true); > > In my code I am explicitly calling close on my connections everywhere > as far as I can tell but I still run out of connections while running > my test cases. If I increase the max connections then I get further > through the tests before running out but I am sure this is an > indication of problems. > I am including the stacktrace which appears when the connections run > out below if it helps. > > I am open to any possible suggestions. > :-) > -AZ > > INFO Logging the stack trace by which the overdue resource was > checked-out. [2008-11-06 16:39:58,812] (BasicResourcePool.java:1395) > java.lang.Exception: DEBUG ONLY: Overdue resource check-out stack trace. > at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:506) > at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525) > at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128) > at org.dspace.database.DSpaceDataSource.getConnection(DSpaceDataSource.java:212) > at org.sakaiproject.genericdao.springjdbc.SmartDataSourceWrapper.getConnection(SmartDataSourceWrapper.java:53) > at org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getNewConnection(ThreadboundConnectionsDataSourceWrapper.java:114) > at org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.createBindWrapConnection(ThreadboundConnectionsDataSourceWrapper.java:91) > at org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getConnection(ThreadboundConnectionsDataSourceWrapper.java:133) > at org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getConnection(ThreadboundConnectionsDataSourceWrapper.java:126) > at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:113) > at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:79) > at org.springframework.jdbc.core.support.JdbcDaoSupport.getConnection(JdbcDaoSupport.java:132) > at org.sakaiproject.genericdao.springjdbc.JdbcGenericDao.commitTransaction(JdbcGenericDao.java:1057) > at org.dspace.services.user.UserDAOTest.initDB(UserDAOTest.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.junit.internal.runners.ClassRoadie.runBefores(ClassRoadie.java:49) > at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:36) > at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) > INFO Destroying connection (2rvxw07xvtfzzt13e7k5w|d47c65): > org.apache.derby.impl.jdbc.EmbedConnection30@10970704 (XID = 144), > (SESSIONID = 1), (DATABASE = DSpaceDerby), (DRDAID = null) > [2008-11-06 16:39:58,815] (DSpace > TestingConnectionCustomizer.java:41) > > |
From: Steve W. <swa...@mc...> - 2008-11-07 00:40:54
|
No. Nothing in the chain would ever close the Connection directly, because the stack trace is truncated at checkoutResource(). This is a c3p0 debugging facility, it takes a snapshot of the stack trace that checks out a Connection, so you can know who to blame if it doesn't get checked back in. You need to look at the application level code that is calling into c3p0 in this stack trace, and think hard about how those Connections get closed, or, more to the point, how they sometimes do not. After c3p0 times out your unreturned Connection, it would be able to get more, but that's a long time to wait, and very bad hygiene. You need to fix the leak. In your 1 Connection example, you'd exhaust the pool, then have to wait 10 secs before the next checkout. c3p0 doesn't abandon objects lightly. smiles, Steve On Nov 6, 2008, at 12:27 PM, Aaron Zeckoski wrote: > Sorry to be dense, can you elaborate on this statement? > "The stack trace shown is the code that's leaking Connections." > > Are you saying that something in that chain is not closing up the > connections (the end of the chain is C3P0 so it seems that the thing > responsible would be it in this case) or that something previously did > not close the connection and this stacktrace is what occurs when it > attempts to get the new connection but cannot? > > Also, if the connection is closed but the connection object is being > held onto somewhere would this stop C3P0 from being able to give me > another one or does it just abandon the object and create new ones? > > -AZ > > > On Thu, Nov 6, 2008 at 5:17 PM, Steve Waldman <swa...@mc...> > wrote: >> The stack trace shown is the code that's leaking Connections. >> Whatever's >> acquiring Connections through that stack trace is failing to >> close() them. >> Look at where you think you are close()ing these Connections, and >> be sure >> there is no codepath that could avoid the close(). That is, the >> close() >> should be in a finally where the getConnection() call is in an >> associated >> try, and there should be no way that the finally block could exit >> (for >> example, on an earlier Exception) without close() being called. >> >> smiles, >> Steve >> >> >> On Nov 6, 2008, at 12:06 PM, Aaron Zeckoski wrote: >> >>> Then my tests get a little further before running out. >>> It still does not solve the underlyig issue though. >>> Note that this is for testing (i.e. running programmatic tests) >>> only. >>> -AZ >>> >>> >>> On Thu, Nov 6, 2008 at 5:02 PM, Adrian Woodhead <ad...@la...> >>> wrote: >>>> >>>> cpds.setMaxPoolSize(1); >>>> >>>> >>>> Doesn't creating a pool of size 1 defeat the point of using a >>>> connection >>>> pool? What if you increase that to something like 10? >>>> >>>> Aaron Zeckoski wrote: >>>>> >>>>> I am running out of connections with a ComboPooledDataSource and I >>>>> need some tips on figuring out why. >>>>> I have these settings for testing: >>>>> cpds.setAutoCommitOnClose(false); >>>>> cpds.setAcquireIncrement(1); >>>>> cpds.setMinPoolSize(1); >>>>> cpds.setInitialPoolSize(1); >>>>> cpds.setMaxPoolSize(1); >>>>> // might need to comment these out for debugging >>>>> cpds.setUnreturnedConnectionTimeout(10); >>>>> cpds.setDebugUnreturnedConnectionStackTraces(true); >>>>> >>>>> In my code I am explicitly calling close on my connections >>>>> everywhere >>>>> as far as I can tell but I still run out of connections while >>>>> running >>>>> my test cases. If I increase the max connections then I get >>>>> further >>>>> through the tests before running out but I am sure this is an >>>>> indication of problems. >>>>> I am including the stacktrace which appears when the connections >>>>> run >>>>> out below if it helps. >>>>> >>>>> I am open to any possible suggestions. >>>>> :-) >>>>> -AZ >>>>> >>>>> INFO Logging the stack trace by which the overdue resource was >>>>> checked-out. [2008-11-06 16:39:58,812] (BasicResourcePool.java: >>>>> 1395) >>>>> java.lang.Exception: DEBUG ONLY: Overdue resource check-out >>>>> stack trace. >>>>> at >>>>> >>>>> com >>>>> .mchange >>>>> .v2 >>>>> .resourcepool >>>>> .BasicResourcePool.checkoutResource(BasicResourcePool.java:506) >>>>> at >>>>> >>>>> com >>>>> .mchange >>>>> .v2 >>>>> .c3p0 >>>>> .impl >>>>> .C3P0PooledConnectionPool >>>>> .checkoutPooledConnection(C3P0PooledConnectionPool.java:525) >>>>> at >>>>> >>>>> com >>>>> .mchange >>>>> .v2 >>>>> .c3p0 >>>>> .impl >>>>> .AbstractPoolBackedDataSource >>>>> .getConnection(AbstractPoolBackedDataSource.java:128) >>>>> at >>>>> >>>>> org >>>>> .dspace >>>>> .database.DSpaceDataSource.getConnection(DSpaceDataSource.java: >>>>> 212) >>>>> at >>>>> >>>>> org >>>>> .sakaiproject >>>>> .genericdao >>>>> .springjdbc >>>>> .SmartDataSourceWrapper >>>>> .getConnection(SmartDataSourceWrapper.java:53) >>>>> at >>>>> >>>>> org >>>>> .sakaiproject >>>>> .genericdao >>>>> .springjdbc >>>>> .ThreadboundConnectionsDataSourceWrapper >>>>> .getNewConnection(ThreadboundConnectionsDataSourceWrapper.java: >>>>> 114) >>>>> at >>>>> >>>>> org >>>>> .sakaiproject >>>>> .genericdao >>>>> .springjdbc >>>>> .ThreadboundConnectionsDataSourceWrapper >>>>> .createBindWrapConnection >>>>> (ThreadboundConnectionsDataSourceWrapper.java:91) >>>>> at >>>>> >>>>> org >>>>> .sakaiproject >>>>> .genericdao >>>>> .springjdbc >>>>> .ThreadboundConnectionsDataSourceWrapper >>>>> .getConnection(ThreadboundConnectionsDataSourceWrapper.java:133) >>>>> at >>>>> >>>>> org >>>>> .sakaiproject >>>>> .genericdao >>>>> .springjdbc >>>>> .ThreadboundConnectionsDataSourceWrapper >>>>> .getConnection(ThreadboundConnectionsDataSourceWrapper.java:126) >>>>> at >>>>> >>>>> org >>>>> .springframework >>>>> .jdbc >>>>> .datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java: >>>>> 113) >>>>> at >>>>> >>>>> org >>>>> .springframework >>>>> .jdbc >>>>> .datasource.DataSourceUtils.getConnection(DataSourceUtils.java:79) >>>>> at >>>>> >>>>> org >>>>> .springframework >>>>> .jdbc >>>>> .core.support.JdbcDaoSupport.getConnection(JdbcDaoSupport.java: >>>>> 132) >>>>> at >>>>> >>>>> org >>>>> .sakaiproject >>>>> .genericdao >>>>> .springjdbc.JdbcGenericDao.commitTransaction(JdbcGenericDao.java: >>>>> 1057) >>>>> at >>>>> org.dspace.services.user.UserDAOTest.initDB(UserDAOTest.java:54) >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>> at >>>>> >>>>> sun >>>>> .reflect >>>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>>>> at >>>>> >>>>> sun >>>>> .reflect >>>>> .DelegatingMethodAccessorImpl >>>>> .invoke(DelegatingMethodAccessorImpl.java:25) >>>>> at java.lang.reflect.Method.invoke(Method.java:585) >>>>> at >>>>> org >>>>> .junit.internal.runners.ClassRoadie.runBefores(ClassRoadie.java: >>>>> 49) >>>>> at >>>>> org >>>>> .junit >>>>> .internal.runners.ClassRoadie.runProtected(ClassRoadie.java:36) >>>>> at >>>>> >>>>> org >>>>> .junit >>>>> .internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) >>>>> at >>>>> >>>>> org >>>>> .eclipse >>>>> .jdt >>>>> .internal >>>>> .junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java: >>>>> 45) >>>>> at >>>>> >>>>> org >>>>> .eclipse >>>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java: >>>>> 38) >>>>> at >>>>> >>>>> org >>>>> .eclipse >>>>> .jdt >>>>> .internal >>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) >>>>> at >>>>> >>>>> org >>>>> .eclipse >>>>> .jdt >>>>> .internal >>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) >>>>> at >>>>> >>>>> org >>>>> .eclipse >>>>> .jdt >>>>> .internal >>>>> .junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) >>>>> at >>>>> >>>>> org >>>>> .eclipse >>>>> .jdt >>>>> .internal >>>>> .junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) >>>>> INFO Destroying connection (2rvxw07xvtfzzt13e7k5w|d47c65): >>>>> org.apache.derby.impl.jdbc.EmbedConnection30@10970704 (XID = 144), >>>>> (SESSIONID = 1), (DATABASE = DSpaceDerby), (DRDAID = null) >>>>> [2008-11-06 16:39:58,815] (DSpace >>>>> TestingConnectionCustomizer.java:41) >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> Aaron Zeckoski (aa...@vt...) >>> Senior Research Engineer - CARET - Cambridge University >>> [http://bugs.sakaiproject.org/confluence/display/~aaronz/] >>> Sakai Fellow - [http://aaronz-sakai.blogspot.com/] >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>> challenge >>> Build the coolest Linux based applications with Moblin SDK & win >>> great >>> prizes >>> Grand prize is a trip for two to an Open Source event anywhere in >>> the >>> world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> c3p0-users mailing list >>> c3p...@li... >>> https://lists.sourceforge.net/lists/listinfo/c3p0-users >> >> ~oo~ >> Steve Waldman >> swa...@mc... >> >> >> >> > > > > -- > Aaron Zeckoski (aa...@vt...) > Senior Research Engineer - CARET - Cambridge University > [http://bugs.sakaiproject.org/confluence/display/~aaronz/] > Sakai Fellow - [http://aaronz-sakai.blogspot.com/] ~oo~ Steve Waldman swa...@mc... |
From: Aaron Z. <aa...@vt...> - 2008-11-07 08:54:47
|
Ah, that's a very helpful, excellent, and clear description. Thanks very much! So, what about the case where I have closed the connection but something has a reference to the Connection object. Do you know if this would stop c3p0 from issuing a new one on a call to getConnection? It really looks like I am calling conn.close() and the end of my first test but the very next test feezes while waiting on the first ds.getConnection() call. I have the latest version of c3p0. -AZ On Fri, Nov 7, 2008 at 12:39 AM, Steve Waldman <swa...@mc...> wrote: > No. Nothing in the chain would ever close the Connection directly, because > the stack trace is truncated at checkoutResource(). This is a c3p0 debugging > facility, it takes a snapshot of the stack trace that checks out a > Connection, so you can know who to blame if it doesn't get checked back in. > You need to look at the application level code that is calling into c3p0 in > this stack trace, and think hard about how those Connections get closed, or, > more to the point, how they sometimes do not. > > After c3p0 times out your unreturned Connection, it would be able to get > more, but that's a long time to wait, and very bad hygiene. You need to fix > the leak. In your 1 Connection example, you'd exhaust the pool, then have to > wait 10 secs before the next checkout. c3p0 doesn't abandon objects lightly. > > smiles, > Steve > > > On Nov 6, 2008, at 12:27 PM, Aaron Zeckoski wrote: > >> Sorry to be dense, can you elaborate on this statement? >> "The stack trace shown is the code that's leaking Connections." >> >> Are you saying that something in that chain is not closing up the >> connections (the end of the chain is C3P0 so it seems that the thing >> responsible would be it in this case) or that something previously did >> not close the connection and this stacktrace is what occurs when it >> attempts to get the new connection but cannot? >> >> Also, if the connection is closed but the connection object is being >> held onto somewhere would this stop C3P0 from being able to give me >> another one or does it just abandon the object and create new ones? >> >> -AZ >> >> >> On Thu, Nov 6, 2008 at 5:17 PM, Steve Waldman <swa...@mc...> >> wrote: >>> >>> The stack trace shown is the code that's leaking Connections. Whatever's >>> acquiring Connections through that stack trace is failing to close() >>> them. >>> Look at where you think you are close()ing these Connections, and be sure >>> there is no codepath that could avoid the close(). That is, the close() >>> should be in a finally where the getConnection() call is in an associated >>> try, and there should be no way that the finally block could exit (for >>> example, on an earlier Exception) without close() being called. >>> >>> smiles, >>> Steve >>> >>> >>> On Nov 6, 2008, at 12:06 PM, Aaron Zeckoski wrote: >>> >>>> Then my tests get a little further before running out. >>>> It still does not solve the underlyig issue though. >>>> Note that this is for testing (i.e. running programmatic tests) only. >>>> -AZ >>>> >>>> >>>> On Thu, Nov 6, 2008 at 5:02 PM, Adrian Woodhead <ad...@la...> wrote: >>>>> >>>>> cpds.setMaxPoolSize(1); >>>>> >>>>> >>>>> Doesn't creating a pool of size 1 defeat the point of using a >>>>> connection >>>>> pool? What if you increase that to something like 10? >>>>> >>>>> Aaron Zeckoski wrote: >>>>>> >>>>>> I am running out of connections with a ComboPooledDataSource and I >>>>>> need some tips on figuring out why. >>>>>> I have these settings for testing: >>>>>> cpds.setAutoCommitOnClose(false); >>>>>> cpds.setAcquireIncrement(1); >>>>>> cpds.setMinPoolSize(1); >>>>>> cpds.setInitialPoolSize(1); >>>>>> cpds.setMaxPoolSize(1); >>>>>> // might need to comment these out for debugging >>>>>> cpds.setUnreturnedConnectionTimeout(10); >>>>>> cpds.setDebugUnreturnedConnectionStackTraces(true); >>>>>> >>>>>> In my code I am explicitly calling close on my connections everywhere >>>>>> as far as I can tell but I still run out of connections while running >>>>>> my test cases. If I increase the max connections then I get further >>>>>> through the tests before running out but I am sure this is an >>>>>> indication of problems. >>>>>> I am including the stacktrace which appears when the connections run >>>>>> out below if it helps. >>>>>> >>>>>> I am open to any possible suggestions. >>>>>> :-) >>>>>> -AZ >>>>>> >>>>>> INFO Logging the stack trace by which the overdue resource was >>>>>> checked-out. [2008-11-06 16:39:58,812] (BasicResourcePool.java:1395) >>>>>> java.lang.Exception: DEBUG ONLY: Overdue resource check-out stack >>>>>> trace. >>>>>> at >>>>>> >>>>>> >>>>>> com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:506) >>>>>> at >>>>>> >>>>>> >>>>>> com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525) >>>>>> at >>>>>> >>>>>> >>>>>> com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128) >>>>>> at >>>>>> >>>>>> >>>>>> org.dspace.database.DSpaceDataSource.getConnection(DSpaceDataSource.java:212) >>>>>> at >>>>>> >>>>>> >>>>>> org.sakaiproject.genericdao.springjdbc.SmartDataSourceWrapper.getConnection(SmartDataSourceWrapper.java:53) >>>>>> at >>>>>> >>>>>> >>>>>> org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getNewConnection(ThreadboundConnectionsDataSourceWrapper.java:114) >>>>>> at >>>>>> >>>>>> >>>>>> org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.createBindWrapConnection(ThreadboundConnectionsDataSourceWrapper.java:91) >>>>>> at >>>>>> >>>>>> >>>>>> org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getConnection(ThreadboundConnectionsDataSourceWrapper.java:133) >>>>>> at >>>>>> >>>>>> >>>>>> org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getConnection(ThreadboundConnectionsDataSourceWrapper.java:126) >>>>>> at >>>>>> >>>>>> >>>>>> org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:113) >>>>>> at >>>>>> >>>>>> >>>>>> org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:79) >>>>>> at >>>>>> >>>>>> >>>>>> org.springframework.jdbc.core.support.JdbcDaoSupport.getConnection(JdbcDaoSupport.java:132) >>>>>> at >>>>>> >>>>>> >>>>>> org.sakaiproject.genericdao.springjdbc.JdbcGenericDao.commitTransaction(JdbcGenericDao.java:1057) >>>>>> at org.dspace.services.user.UserDAOTest.initDB(UserDAOTest.java:54) >>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>> at >>>>>> >>>>>> >>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>>>>> at >>>>>> >>>>>> >>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>>>>> at java.lang.reflect.Method.invoke(Method.java:585) >>>>>> at >>>>>> org.junit.internal.runners.ClassRoadie.runBefores(ClassRoadie.java:49) >>>>>> at >>>>>> >>>>>> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:36) >>>>>> at >>>>>> >>>>>> >>>>>> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) >>>>>> at >>>>>> >>>>>> >>>>>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) >>>>>> at >>>>>> >>>>>> >>>>>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) >>>>>> at >>>>>> >>>>>> >>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) >>>>>> at >>>>>> >>>>>> >>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) >>>>>> at >>>>>> >>>>>> >>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) >>>>>> at >>>>>> >>>>>> >>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) >>>>>> INFO Destroying connection (2rvxw07xvtfzzt13e7k5w|d47c65): >>>>>> org.apache.derby.impl.jdbc.EmbedConnection30@10970704 (XID = 144), >>>>>> (SESSIONID = 1), (DATABASE = DSpaceDerby), (DRDAID = null) >>>>>> [2008-11-06 16:39:58,815] (DSpace >>>>>> TestingConnectionCustomizer.java:41) >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Aaron Zeckoski (aa...@vt...) >>>> Senior Research Engineer - CARET - Cambridge University >>>> [http://bugs.sakaiproject.org/confluence/display/~aaronz/] >>>> Sakai Fellow - [http://aaronz-sakai.blogspot.com/] >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>>> challenge >>>> Build the coolest Linux based applications with Moblin SDK & win great >>>> prizes >>>> Grand prize is a trip for two to an Open Source event anywhere in the >>>> world >>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>> _______________________________________________ >>>> c3p0-users mailing list >>>> c3p...@li... >>>> https://lists.sourceforge.net/lists/listinfo/c3p0-users >>> >>> ~oo~ >>> Steve Waldman >>> swa...@mc... >>> >>> >>> >>> >> >> >> >> -- >> Aaron Zeckoski (aa...@vt...) >> Senior Research Engineer - CARET - Cambridge University >> [http://bugs.sakaiproject.org/confluence/display/~aaronz/] >> Sakai Fellow - [http://aaronz-sakai.blogspot.com/] > > ~oo~ > Steve Waldman > swa...@mc... > > > > -- Aaron Zeckoski (aa...@vt...) Senior Research Engineer - CARET - Cambridge University [http://bugs.sakaiproject.org/confluence/display/~aaronz/] Sakai Fellow - [http://aaronz-sakai.blogspot.com/] |
From: Steve W. <swa...@mc...> - 2008-11-07 15:22:58
|
No... a reference to the dead Connection wouldn't hold anything up if it's been properly closed. Looks can be deceiving: you might try instrumenting the close somehow, e.g. logging something just before and just after (where as Exception during would skip the just after) to be sure. And really, you should be using the robust resource cleanup idiom: Connection c = null; OtherResource or = null; try { c = cpds.getConnection(); or = getOtherResource() // do stuff // ... } finally { try { if (or != null) or.close(); } catch (Exception e) { e.printStackTrace(); } try { if (c != null) c.close(); } catch (Exception e) { e.printStackTrace(); } } Note that the finally clause will definitely be executed if the Connection is acquired, and there is a best-attempt close() of each resource: If or fails to close(), that Exception won't prevent the attempt to close() the Connection. From your stack traces, it looks like you are using a lot of framework code, suggesting that the codepath between Connection acquisition and teardown may not be obvious. One big advantage of a Connection pool is that the overhead of acquiring a Connection is so low, that you can acquire it as need it and close() it immediately, per the code above. There's no need to open a Connection in a set up step, hold it as a member, and then hope some tear down code properly disposes of it later on. As Keynes famously put it, there's many a slip 'twixt the cup and the lip. smiles, Steve On Nov 7, 2008, at 3:54 AM, Aaron Zeckoski wrote: > Ah, that's a very helpful, excellent, and clear description. Thanks > very much! > > So, what about the case where I have closed the connection but > something has a reference to the Connection object. Do you know if > this would stop c3p0 from issuing a new one on a call to > getConnection? It really looks like I am calling conn.close() and the > end of my first test but the very next test feezes while waiting on > the first ds.getConnection() call. I have the latest version of c3p0. > -AZ > > > On Fri, Nov 7, 2008 at 12:39 AM, Steve Waldman > <swa...@mc...> wrote: >> No. Nothing in the chain would ever close the Connection directly, >> because >> the stack trace is truncated at checkoutResource(). This is a c3p0 >> debugging >> facility, it takes a snapshot of the stack trace that checks out a >> Connection, so you can know who to blame if it doesn't get checked >> back in. >> You need to look at the application level code that is calling into >> c3p0 in >> this stack trace, and think hard about how those Connections get >> closed, or, >> more to the point, how they sometimes do not. >> >> After c3p0 times out your unreturned Connection, it would be able >> to get >> more, but that's a long time to wait, and very bad hygiene. You >> need to fix >> the leak. In your 1 Connection example, you'd exhaust the pool, >> then have to >> wait 10 secs before the next checkout. c3p0 doesn't abandon objects >> lightly. >> >> smiles, >> Steve >> >> >> On Nov 6, 2008, at 12:27 PM, Aaron Zeckoski wrote: >> >>> Sorry to be dense, can you elaborate on this statement? >>> "The stack trace shown is the code that's leaking Connections." >>> >>> Are you saying that something in that chain is not closing up the >>> connections (the end of the chain is C3P0 so it seems that the thing >>> responsible would be it in this case) or that something previously >>> did >>> not close the connection and this stacktrace is what occurs when it >>> attempts to get the new connection but cannot? >>> >>> Also, if the connection is closed but the connection object is being >>> held onto somewhere would this stop C3P0 from being able to give me >>> another one or does it just abandon the object and create new ones? >>> >>> -AZ >>> >>> >>> On Thu, Nov 6, 2008 at 5:17 PM, Steve Waldman <swa...@mc...> >>> wrote: >>>> >>>> The stack trace shown is the code that's leaking Connections. >>>> Whatever's >>>> acquiring Connections through that stack trace is failing to >>>> close() >>>> them. >>>> Look at where you think you are close()ing these Connections, and >>>> be sure >>>> there is no codepath that could avoid the close(). That is, the >>>> close() >>>> should be in a finally where the getConnection() call is in an >>>> associated >>>> try, and there should be no way that the finally block could exit >>>> (for >>>> example, on an earlier Exception) without close() being called. >>>> >>>> smiles, >>>> Steve >>>> >>>> >>>> On Nov 6, 2008, at 12:06 PM, Aaron Zeckoski wrote: >>>> >>>>> Then my tests get a little further before running out. >>>>> It still does not solve the underlyig issue though. >>>>> Note that this is for testing (i.e. running programmatic tests) >>>>> only. >>>>> -AZ >>>>> >>>>> >>>>> On Thu, Nov 6, 2008 at 5:02 PM, Adrian Woodhead <ad...@la...> >>>>> wrote: >>>>>> >>>>>> cpds.setMaxPoolSize(1); >>>>>> >>>>>> >>>>>> Doesn't creating a pool of size 1 defeat the point of using a >>>>>> connection >>>>>> pool? What if you increase that to something like 10? >>>>>> >>>>>> Aaron Zeckoski wrote: >>>>>>> >>>>>>> I am running out of connections with a ComboPooledDataSource >>>>>>> and I >>>>>>> need some tips on figuring out why. >>>>>>> I have these settings for testing: >>>>>>> cpds.setAutoCommitOnClose(false); >>>>>>> cpds.setAcquireIncrement(1); >>>>>>> cpds.setMinPoolSize(1); >>>>>>> cpds.setInitialPoolSize(1); >>>>>>> cpds.setMaxPoolSize(1); >>>>>>> // might need to comment these out for debugging >>>>>>> cpds.setUnreturnedConnectionTimeout(10); >>>>>>> cpds.setDebugUnreturnedConnectionStackTraces(true); >>>>>>> >>>>>>> In my code I am explicitly calling close on my connections >>>>>>> everywhere >>>>>>> as far as I can tell but I still run out of connections while >>>>>>> running >>>>>>> my test cases. If I increase the max connections then I get >>>>>>> further >>>>>>> through the tests before running out but I am sure this is an >>>>>>> indication of problems. >>>>>>> I am including the stacktrace which appears when the >>>>>>> connections run >>>>>>> out below if it helps. >>>>>>> >>>>>>> I am open to any possible suggestions. >>>>>>> :-) >>>>>>> -AZ >>>>>>> >>>>>>> INFO Logging the stack trace by which the overdue resource was >>>>>>> checked-out. [2008-11-06 16:39:58,812] >>>>>>> (BasicResourcePool.java:1395) >>>>>>> java.lang.Exception: DEBUG ONLY: Overdue resource check-out >>>>>>> stack >>>>>>> trace. >>>>>>> at >>>>>>> >>>>>>> >>>>>>> com >>>>>>> .mchange >>>>>>> .v2 >>>>>>> .resourcepool >>>>>>> .BasicResourcePool.checkoutResource(BasicResourcePool.java:506) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> com >>>>>>> .mchange >>>>>>> .v2 >>>>>>> .c3p0 >>>>>>> .impl >>>>>>> .C3P0PooledConnectionPool >>>>>>> .checkoutPooledConnection(C3P0PooledConnectionPool.java:525) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> com >>>>>>> .mchange >>>>>>> .v2 >>>>>>> .c3p0 >>>>>>> .impl >>>>>>> .AbstractPoolBackedDataSource >>>>>>> .getConnection(AbstractPoolBackedDataSource.java:128) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .dspace >>>>>>> .database.DSpaceDataSource.getConnection(DSpaceDataSource.java: >>>>>>> 212) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .sakaiproject >>>>>>> .genericdao >>>>>>> .springjdbc >>>>>>> .SmartDataSourceWrapper >>>>>>> .getConnection(SmartDataSourceWrapper.java:53) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .sakaiproject >>>>>>> .genericdao >>>>>>> .springjdbc >>>>>>> .ThreadboundConnectionsDataSourceWrapper >>>>>>> .getNewConnection(ThreadboundConnectionsDataSourceWrapper.java: >>>>>>> 114) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .sakaiproject >>>>>>> .genericdao >>>>>>> .springjdbc >>>>>>> .ThreadboundConnectionsDataSourceWrapper >>>>>>> .createBindWrapConnection >>>>>>> (ThreadboundConnectionsDataSourceWrapper.java:91) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .sakaiproject >>>>>>> .genericdao >>>>>>> .springjdbc >>>>>>> .ThreadboundConnectionsDataSourceWrapper >>>>>>> .getConnection(ThreadboundConnectionsDataSourceWrapper.java:133) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .sakaiproject >>>>>>> .genericdao >>>>>>> .springjdbc >>>>>>> .ThreadboundConnectionsDataSourceWrapper >>>>>>> .getConnection(ThreadboundConnectionsDataSourceWrapper.java:126) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .springframework >>>>>>> .jdbc >>>>>>> .datasource >>>>>>> .DataSourceUtils.doGetConnection(DataSourceUtils.java:113) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .springframework >>>>>>> .jdbc >>>>>>> .datasource.DataSourceUtils.getConnection(DataSourceUtils.java: >>>>>>> 79) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .springframework >>>>>>> .jdbc >>>>>>> .core.support.JdbcDaoSupport.getConnection(JdbcDaoSupport.java: >>>>>>> 132) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .sakaiproject >>>>>>> .genericdao >>>>>>> .springjdbc >>>>>>> .JdbcGenericDao.commitTransaction(JdbcGenericDao.java:1057) >>>>>>> at >>>>>>> org.dspace.services.user.UserDAOTest.initDB(UserDAOTest.java:54) >>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> sun >>>>>>> .reflect >>>>>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: >>>>>>> 39) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> sun >>>>>>> .reflect >>>>>>> .DelegatingMethodAccessorImpl >>>>>>> .invoke(DelegatingMethodAccessorImpl.java:25) >>>>>>> at java.lang.reflect.Method.invoke(Method.java:585) >>>>>>> at >>>>>>> org >>>>>>> .junit >>>>>>> .internal.runners.ClassRoadie.runBefores(ClassRoadie.java:49) >>>>>>> at >>>>>>> >>>>>>> org >>>>>>> .junit >>>>>>> .internal.runners.ClassRoadie.runProtected(ClassRoadie.java:36) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .junit >>>>>>> .internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java: >>>>>>> 42) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .eclipse >>>>>>> .jdt >>>>>>> .internal >>>>>>> .junit4 >>>>>>> .runner.JUnit4TestReference.run(JUnit4TestReference.java:45) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .eclipse >>>>>>> .jdt >>>>>>> .internal.junit.runner.TestExecution.run(TestExecution.java:38) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .eclipse >>>>>>> .jdt >>>>>>> .internal >>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java: >>>>>>> 460) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .eclipse >>>>>>> .jdt >>>>>>> .internal >>>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java: >>>>>>> 673) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .eclipse >>>>>>> .jdt >>>>>>> .internal >>>>>>> .junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org >>>>>>> .eclipse >>>>>>> .jdt >>>>>>> .internal >>>>>>> .junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) >>>>>>> INFO Destroying connection (2rvxw07xvtfzzt13e7k5w|d47c65): >>>>>>> org.apache.derby.impl.jdbc.EmbedConnection30@10970704 (XID = >>>>>>> 144), >>>>>>> (SESSIONID = 1), (DATABASE = DSpaceDerby), (DRDAID = null) >>>>>>> [2008-11-06 16:39:58,815] (DSpace >>>>>>> TestingConnectionCustomizer.java:41) >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Aaron Zeckoski (aa...@vt...) >>>>> Senior Research Engineer - CARET - Cambridge University >>>>> [http://bugs.sakaiproject.org/confluence/display/~aaronz/] >>>>> Sakai Fellow - [http://aaronz-sakai.blogspot.com/] >>>>> >>>>> >>>>> ------------------------------------------------------------------------- >>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>>>> challenge >>>>> Build the coolest Linux based applications with Moblin SDK & win >>>>> great >>>>> prizes >>>>> Grand prize is a trip for two to an Open Source event anywhere >>>>> in the >>>>> world >>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>> _______________________________________________ >>>>> c3p0-users mailing list >>>>> c3p...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/c3p0-users >>>> >>>> ~oo~ >>>> Steve Waldman >>>> swa...@mc... >>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Aaron Zeckoski (aa...@vt...) >>> Senior Research Engineer - CARET - Cambridge University >>> [http://bugs.sakaiproject.org/confluence/display/~aaronz/] >>> Sakai Fellow - [http://aaronz-sakai.blogspot.com/] >> >> ~oo~ >> Steve Waldman >> swa...@mc... >> >> >> >> > > > > -- > Aaron Zeckoski (aa...@vt...) > Senior Research Engineer - CARET - Cambridge University > [http://bugs.sakaiproject.org/confluence/display/~aaronz/] > Sakai Fellow - [http://aaronz-sakai.blogspot.com/] ~oo~ Steve Waldman swa...@mc... |
From: Aaron Z. <aa...@vt...> - 2008-11-07 16:05:54
|
OK, that is good news. I will look more closely then. There must be something that is not closing the connection correctly. Perhaps a failure somewhere. I think a tracing session is needed. You are quite right. We are attempting to limit load on the system by sharing a connection for a request and we do not commit the connection until the end of the request (whether shared or not). We have toyed with the idea that perhaps we could simply open a new connection for each thing in the request and then close them all at the end. I was concerned this might overload the database with probably 3-4 connections open in a request on average but maybe this is not as big a deal as I think. If I read you right you are suggesting that we could do an approach like this and not worry about it too much? Thanks again for the advice. -AZ On Fri, Nov 7, 2008 at 3:19 PM, Steve Waldman <swa...@mc...> wrote: > No... a reference to the dead Connection wouldn't hold anything up if it's > been properly closed. Looks can be deceiving: you might try instrumenting > the close somehow, e.g. logging something just before and just after (where > as Exception during would skip the just after) to be sure. And really, you > should be using the robust resource cleanup idiom: > > Connection c = null; > OtherResource or = null; > > try > { > c = cpds.getConnection(); > or = getOtherResource() > > // do stuff > // ... > } > finally > { > try { if (or != null) or.close(); } > catch (Exception e) { e.printStackTrace(); } > > try { if (c != null) c.close(); } > catch (Exception e) { e.printStackTrace(); } > } > > Note that the finally clause will definitely be executed if the Connection > is acquired, and there is a best-attempt close() of each resource: If or > fails to close(), that Exception won't prevent the attempt to close() the > Connection. > > From your stack traces, it looks like you are using a lot of framework code, > suggesting that the codepath between Connection acquisition and teardown may > not be obvious. One big advantage of a Connection pool is that the overhead > of acquiring a Connection is so low, that you can acquire it as need it and > close() it immediately, per the code above. There's no need to open a > Connection in a set up step, hold it as a member, and then hope some tear > down code properly disposes of it later on. As Keynes famously put it, > there's many a slip 'twixt the cup and the lip. > > smiles, > Steve > > > On Nov 7, 2008, at 3:54 AM, Aaron Zeckoski wrote: > >> Ah, that's a very helpful, excellent, and clear description. Thanks very >> much! >> >> So, what about the case where I have closed the connection but >> something has a reference to the Connection object. Do you know if >> this would stop c3p0 from issuing a new one on a call to >> getConnection? It really looks like I am calling conn.close() and the >> end of my first test but the very next test feezes while waiting on >> the first ds.getConnection() call. I have the latest version of c3p0. >> -AZ >> >> >> On Fri, Nov 7, 2008 at 12:39 AM, Steve Waldman <swa...@mc...> >> wrote: >>> >>> No. Nothing in the chain would ever close the Connection directly, >>> because >>> the stack trace is truncated at checkoutResource(). This is a c3p0 >>> debugging >>> facility, it takes a snapshot of the stack trace that checks out a >>> Connection, so you can know who to blame if it doesn't get checked back >>> in. >>> You need to look at the application level code that is calling into c3p0 >>> in >>> this stack trace, and think hard about how those Connections get closed, >>> or, >>> more to the point, how they sometimes do not. >>> >>> After c3p0 times out your unreturned Connection, it would be able to get >>> more, but that's a long time to wait, and very bad hygiene. You need to >>> fix >>> the leak. In your 1 Connection example, you'd exhaust the pool, then have >>> to >>> wait 10 secs before the next checkout. c3p0 doesn't abandon objects >>> lightly. >>> >>> smiles, >>> Steve >>> >>> >>> On Nov 6, 2008, at 12:27 PM, Aaron Zeckoski wrote: >>> >>>> Sorry to be dense, can you elaborate on this statement? >>>> "The stack trace shown is the code that's leaking Connections." >>>> >>>> Are you saying that something in that chain is not closing up the >>>> connections (the end of the chain is C3P0 so it seems that the thing >>>> responsible would be it in this case) or that something previously did >>>> not close the connection and this stacktrace is what occurs when it >>>> attempts to get the new connection but cannot? >>>> >>>> Also, if the connection is closed but the connection object is being >>>> held onto somewhere would this stop C3P0 from being able to give me >>>> another one or does it just abandon the object and create new ones? >>>> >>>> -AZ >>>> >>>> >>>> On Thu, Nov 6, 2008 at 5:17 PM, Steve Waldman <swa...@mc...> >>>> wrote: >>>>> >>>>> The stack trace shown is the code that's leaking Connections. >>>>> Whatever's >>>>> acquiring Connections through that stack trace is failing to close() >>>>> them. >>>>> Look at where you think you are close()ing these Connections, and be >>>>> sure >>>>> there is no codepath that could avoid the close(). That is, the close() >>>>> should be in a finally where the getConnection() call is in an >>>>> associated >>>>> try, and there should be no way that the finally block could exit (for >>>>> example, on an earlier Exception) without close() being called. >>>>> >>>>> smiles, >>>>> Steve >>>>> >>>>> >>>>> On Nov 6, 2008, at 12:06 PM, Aaron Zeckoski wrote: >>>>> >>>>>> Then my tests get a little further before running out. >>>>>> It still does not solve the underlyig issue though. >>>>>> Note that this is for testing (i.e. running programmatic tests) only. >>>>>> -AZ >>>>>> >>>>>> >>>>>> On Thu, Nov 6, 2008 at 5:02 PM, Adrian Woodhead <ad...@la...> >>>>>> wrote: >>>>>>> >>>>>>> cpds.setMaxPoolSize(1); >>>>>>> >>>>>>> >>>>>>> Doesn't creating a pool of size 1 defeat the point of using a >>>>>>> connection >>>>>>> pool? What if you increase that to something like 10? >>>>>>> >>>>>>> Aaron Zeckoski wrote: >>>>>>>> >>>>>>>> I am running out of connections with a ComboPooledDataSource and I >>>>>>>> need some tips on figuring out why. >>>>>>>> I have these settings for testing: >>>>>>>> cpds.setAutoCommitOnClose(false); >>>>>>>> cpds.setAcquireIncrement(1); >>>>>>>> cpds.setMinPoolSize(1); >>>>>>>> cpds.setInitialPoolSize(1); >>>>>>>> cpds.setMaxPoolSize(1); >>>>>>>> // might need to comment these out for debugging >>>>>>>> cpds.setUnreturnedConnectionTimeout(10); >>>>>>>> cpds.setDebugUnreturnedConnectionStackTraces(true); >>>>>>>> >>>>>>>> In my code I am explicitly calling close on my connections >>>>>>>> everywhere >>>>>>>> as far as I can tell but I still run out of connections while >>>>>>>> running >>>>>>>> my test cases. If I increase the max connections then I get further >>>>>>>> through the tests before running out but I am sure this is an >>>>>>>> indication of problems. >>>>>>>> I am including the stacktrace which appears when the connections run >>>>>>>> out below if it helps. >>>>>>>> >>>>>>>> I am open to any possible suggestions. >>>>>>>> :-) >>>>>>>> -AZ >>>>>>>> >>>>>>>> INFO Logging the stack trace by which the overdue resource was >>>>>>>> checked-out. [2008-11-06 16:39:58,812] >>>>>>>> (BasicResourcePool.java:1395) >>>>>>>> java.lang.Exception: DEBUG ONLY: Overdue resource check-out stack >>>>>>>> trace. >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:506) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.dspace.database.DSpaceDataSource.getConnection(DSpaceDataSource.java:212) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.sakaiproject.genericdao.springjdbc.SmartDataSourceWrapper.getConnection(SmartDataSourceWrapper.java:53) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getNewConnection(ThreadboundConnectionsDataSourceWrapper.java:114) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.createBindWrapConnection(ThreadboundConnectionsDataSourceWrapper.java:91) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getConnection(ThreadboundConnectionsDataSourceWrapper.java:133) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.sakaiproject.genericdao.springjdbc.ThreadboundConnectionsDataSourceWrapper.getConnection(ThreadboundConnectionsDataSourceWrapper.java:126) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:113) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:79) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.springframework.jdbc.core.support.JdbcDaoSupport.getConnection(JdbcDaoSupport.java:132) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.sakaiproject.genericdao.springjdbc.JdbcGenericDao.commitTransaction(JdbcGenericDao.java:1057) >>>>>>>> at org.dspace.services.user.UserDAOTest.initDB(UserDAOTest.java:54) >>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>>>>>>> at java.lang.reflect.Method.invoke(Method.java:585) >>>>>>>> at >>>>>>>> >>>>>>>> org.junit.internal.runners.ClassRoadie.runBefores(ClassRoadie.java:49) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:36) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) >>>>>>>> INFO Destroying connection (2rvxw07xvtfzzt13e7k5w|d47c65): >>>>>>>> org.apache.derby.impl.jdbc.EmbedConnection30@10970704 (XID = 144), >>>>>>>> (SESSIONID = 1), (DATABASE = DSpaceDerby), (DRDAID = null) >>>>>>>> [2008-11-06 16:39:58,815] (DSpace >>>>>>>> TestingConnectionCustomizer.java:41) >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Aaron Zeckoski (aa...@vt...) >>>>>> Senior Research Engineer - CARET - Cambridge University >>>>>> [http://bugs.sakaiproject.org/confluence/display/~aaronz/] >>>>>> Sakai Fellow - [http://aaronz-sakai.blogspot.com/] >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>>>>> challenge >>>>>> Build the coolest Linux based applications with Moblin SDK & win great >>>>>> prizes >>>>>> Grand prize is a trip for two to an Open Source event anywhere in the >>>>>> world >>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>>> _______________________________________________ >>>>>> c3p0-users mailing list >>>>>> c3p...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/c3p0-users >>>>> >>>>> ~oo~ >>>>> Steve Waldman >>>>> swa...@mc... >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Aaron Zeckoski (aa...@vt...) >>>> Senior Research Engineer - CARET - Cambridge University >>>> [http://bugs.sakaiproject.org/confluence/display/~aaronz/] >>>> Sakai Fellow - [http://aaronz-sakai.blogspot.com/] >>> >>> ~oo~ >>> Steve Waldman >>> swa...@mc... >>> >>> >>> >>> >> >> >> >> -- >> Aaron Zeckoski (aa...@vt...) >> Senior Research Engineer - CARET - Cambridge University >> [http://bugs.sakaiproject.org/confluence/display/~aaronz/] >> Sakai Fellow - [http://aaronz-sakai.blogspot.com/] > > ~oo~ > Steve Waldman > swa...@mc... > > > > -- Aaron Zeckoski (aa...@vt...) Senior Research Engineer - CARET - Cambridge University [http://bugs.sakaiproject.org/confluence/display/~aaronz/] Sakai Fellow - [http://aaronz-sakai.blogspot.com/] |
From: Steve W. <swa...@mc...> - 2008-11-07 16:37:44
|
Yeah... you can control the load on the database with maxPoolSize, and just let everyone grab a Connection as needed, do their work, commit, and close. c3p0 will make this fast (checking out an available, pooled Connection is quick) and let you configure the performance/overhead tradeoff however you like. You won't have to worry about keeping transactions distinct when multiple clients are trying to share a Connection and all that jazz. The approach is simple and sure. The only downside is that it's performant only with a Connection pool -- that is, if you modified the code to acquire Connections directly from a database (rather than from c3p0 or any other reasonable pool), a one- connection-per-client model becomes terribly slow. (But no one goes directly to a database these days in non-trivially complex applications.) smiles, Steve On Nov 7, 2008, at 11:05 AM, Aaron Zeckoski wrote: > OK, that is good news. I will look more closely then. There must be > something that is not closing the connection correctly. Perhaps a > failure somewhere. I think a tracing session is needed. > > You are quite right. We are attempting to limit load on the system by > sharing a connection for a request and we do not commit the connection > until the end of the request (whether shared or not). We have toyed > with the idea that perhaps we could simply open a new connection for > each thing in the request and then close them all at the end. I was > concerned this might overload the database with probably 3-4 > connections open in a request on average but maybe this is not as big > a deal as I think. > > If I read you right you are suggesting that we could do an approach > like this and not worry about it too much? > > Thanks again for the advice. > -AZ > > > On Fri, Nov 7, 2008 at 3:19 PM, Steve Waldman <swa...@mc...> > wrote: >> No... a reference to the dead Connection wouldn't hold anything up >> if it's >> been properly closed. Looks can be deceiving: you might try >> instrumenting >> the close somehow, e.g. logging something just before and just >> after (where >> as Exception during would skip the just after) to be sure. And >> really, you >> should be using the robust resource cleanup idiom: >> >> Connection c = null; >> OtherResource or = null; >> >> try >> { >> c = cpds.getConnection(); >> or = getOtherResource() >> >> // do stuff >> // ... >> } >> finally >> { >> try { if (or != null) or.close(); } >> catch (Exception e) { e.printStackTrace(); } >> >> try { if (c != null) c.close(); } >> catch (Exception e) { e.printStackTrace(); } >> } >> >> Note that the finally clause will definitely be executed if the >> Connection >> is acquired, and there is a best-attempt close() of each resource: >> If or >> fails to close(), that Exception won't prevent the attempt to >> close() the >> Connection. >> >> From your stack traces, it looks like you are using a lot of >> framework code, >> suggesting that the codepath between Connection acquisition and >> teardown may >> not be obvious. One big advantage of a Connection pool is that the >> overhead >> of acquiring a Connection is so low, that you can acquire it as >> need it and >> close() it immediately, per the code above. There's no need to open a >> Connection in a set up step, hold it as a member, and then hope >> some tear >> down code properly disposes of it later on. As Keynes famously put >> it, >> there's many a slip 'twixt the cup and the lip. >> >> smiles, >> Steve >> >> >> On Nov 7, 2008, at 3:54 AM, Aaron Zeckoski wrote: >> >>> Ah, that's a very helpful, excellent, and clear description. >>> Thanks very >>> much! >>> >>> So, what about the case where I have closed the connection but >>> something has a reference to the Connection object. Do you know if >>> this would stop c3p0 from issuing a new one on a call to >>> getConnection? It really looks like I am calling conn.close() and >>> the >>> end of my first test but the very next test feezes while waiting on >>> the first ds.getConnection() call. I have the latest version of >>> c3p0. >>> -AZ >>> >>> >>> On Fri, Nov 7, 2008 at 12:39 AM, Steve Waldman >>> <swa...@mc...> >>> wrote: >>>> >>>> No. Nothing in the chain would ever close the Connection directly, >>>> because >>>> the stack trace is truncated at checkoutResource(). This is a c3p0 >>>> debugging >>>> facility, it takes a snapshot of the stack trace that checks out a >>>> Connection, so you can know who to blame if it doesn't get >>>> checked back >>>> in. >>>> You need to look at the application level code that is calling >>>> into c3p0 >>>> in >>>> this stack trace, and think hard about how those Connections get >>>> closed, >>>> or, >>>> more to the point, how they sometimes do not. >>>> >>>> After c3p0 times out your unreturned Connection, it would be able >>>> to get >>>> more, but that's a long time to wait, and very bad hygiene. You >>>> need to >>>> fix >>>> the leak. In your 1 Connection example, you'd exhaust the pool, >>>> then have >>>> to >>>> wait 10 secs before the next checkout. c3p0 doesn't abandon objects >>>> lightly. >>>> >>>> smiles, >>>> Steve >>>> >>>> >>>> On Nov 6, 2008, at 12:27 PM, Aaron Zeckoski wrote: >>>> >>>>> Sorry to be dense, can you elaborate on this statement? >>>>> "The stack trace shown is the code that's leaking Connections." >>>>> >>>>> Are you saying that something in that chain is not closing up the >>>>> connections (the end of the chain is C3P0 so it seems that the >>>>> thing >>>>> responsible would be it in this case) or that something >>>>> previously did >>>>> not close the connection and this stacktrace is what occurs when >>>>> it >>>>> attempts to get the new connection but cannot? >>>>> >>>>> Also, if the connection is closed but the connection object is >>>>> being >>>>> held onto somewhere would this stop C3P0 from being able to give >>>>> me >>>>> another one or does it just abandon the object and create new >>>>> ones? >>>>> >>>>> -AZ >>>>> >>>>> >>>>> On Thu, Nov 6, 2008 at 5:17 PM, Steve Waldman <swa...@mc... >>>>> > >>>>> wrote: >>>>>> >>>>>> The stack trace shown is the code that's leaking Connections. >>>>>> Whatever's >>>>>> acquiring Connections through that stack trace is failing to >>>>>> close() >>>>>> them. >>>>>> Look at where you think you are close()ing these Connections, >>>>>> and be >>>>>> sure >>>>>> there is no codepath that could avoid the close(). That is, the >>>>>> close() >>>>>> should be in a finally where the getConnection() call is in an >>>>>> associated >>>>>> try, and there should be no way that the finally block could >>>>>> exit (for >>>>>> example, on an earlier Exception) without close() being called. >>>>>> >>>>>> smiles, >>>>>> Steve >>>>>> >>>>>> >>>>>> On Nov 6, 2008, at 12:06 PM, Aaron Zeckoski wrote: >>>>>> >>>>>>> Then my tests get a little further before running out. >>>>>>> It still does not solve the underlyig issue though. >>>>>>> Note that this is for testing (i.e. running programmatic >>>>>>> tests) only. >>>>>>> -AZ >>>>>>> >>>>>>> >>>>>>> On Thu, Nov 6, 2008 at 5:02 PM, Adrian Woodhead <ad...@la...> >>>>>>> wrote: >>>>>>>> >>>>>>>> cpds.setMaxPoolSize(1); >>>>>>>> >>>>>>>> >>>>>>>> Doesn't creating a pool of size 1 defeat the point of using a >>>>>>>> connection >>>>>>>> pool? What if you increase that to something like 10? >>>>>>>> >>>>>>>> Aaron Zeckoski wrote: >>>>>>>>> >>>>>>>>> I am running out of connections with a ComboPooledDataSource >>>>>>>>> and I >>>>>>>>> need some tips on figuring out why. >>>>>>>>> I have these settings for testing: >>>>>>>>> cpds.setAutoCommitOnClose(false); >>>>>>>>> cpds.setAcquireIncrement(1); >>>>>>>>> cpds.setMinPoolSize(1); >>>>>>>>> cpds.setInitialPoolSize(1); >>>>>>>>> cpds.setMaxPoolSize(1); >>>>>>>>> // might need to comment these out for debugging >>>>>>>>> cpds.setUnreturnedConnectionTimeout(10); >>>>>>>>> cpds.setDebugUnreturnedConnectionStackTraces(true); >>>>>>>>> >>>>>>>>> In my code I am explicitly calling close on my connections >>>>>>>>> everywhere >>>>>>>>> as far as I can tell but I still run out of connections while >>>>>>>>> running >>>>>>>>> my test cases. If I increase the max connections then I get >>>>>>>>> further >>>>>>>>> through the tests before running out but I am sure this is an >>>>>>>>> indication of problems. >>>>>>>>> I am including the stacktrace which appears when the >>>>>>>>> connections run >>>>>>>>> out below if it helps. >>>>>>>>> >>>>>>>>> I am open to any possible suggestions. >>>>>>>>> :-) >>>>>>>>> -AZ >>>>>>>>> >>>>>>>>> INFO Logging the stack trace by which the overdue resource was >>>>>>>>> checked-out. [2008-11-06 16:39:58,812] >>>>>>>>> (BasicResourcePool.java:1395) >>>>>>>>> java.lang.Exception: DEBUG ONLY: Overdue resource check-out >>>>>>>>> stack >>>>>>>>> trace. >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> com >>>>>>>>> .mchange >>>>>>>>> .v2 >>>>>>>>> .resourcepool >>>>>>>>> .BasicResourcePool.checkoutResource(BasicResourcePool.java: >>>>>>>>> 506) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> com >>>>>>>>> .mchange >>>>>>>>> .v2 >>>>>>>>> .c3p0 >>>>>>>>> .impl >>>>>>>>> .C3P0PooledConnectionPool >>>>>>>>> .checkoutPooledConnection(C3P0PooledConnectionPool.java:525) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> com >>>>>>>>> .mchange >>>>>>>>> .v2 >>>>>>>>> .c3p0 >>>>>>>>> .impl >>>>>>>>> .AbstractPoolBackedDataSource >>>>>>>>> .getConnection(AbstractPoolBackedDataSource.java:128) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .dspace >>>>>>>>> .database >>>>>>>>> .DSpaceDataSource.getConnection(DSpaceDataSource.java:212) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .sakaiproject >>>>>>>>> .genericdao >>>>>>>>> .springjdbc >>>>>>>>> .SmartDataSourceWrapper >>>>>>>>> .getConnection(SmartDataSourceWrapper.java:53) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .sakaiproject >>>>>>>>> .genericdao >>>>>>>>> .springjdbc >>>>>>>>> .ThreadboundConnectionsDataSourceWrapper >>>>>>>>> .getNewConnection >>>>>>>>> (ThreadboundConnectionsDataSourceWrapper.java:114) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .sakaiproject >>>>>>>>> .genericdao >>>>>>>>> .springjdbc >>>>>>>>> .ThreadboundConnectionsDataSourceWrapper >>>>>>>>> .createBindWrapConnection >>>>>>>>> (ThreadboundConnectionsDataSourceWrapper.java:91) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .sakaiproject >>>>>>>>> .genericdao >>>>>>>>> .springjdbc >>>>>>>>> .ThreadboundConnectionsDataSourceWrapper >>>>>>>>> .getConnection(ThreadboundConnectionsDataSourceWrapper.java: >>>>>>>>> 133) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .sakaiproject >>>>>>>>> .genericdao >>>>>>>>> .springjdbc >>>>>>>>> .ThreadboundConnectionsDataSourceWrapper >>>>>>>>> .getConnection(ThreadboundConnectionsDataSourceWrapper.java: >>>>>>>>> 126) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .springframework >>>>>>>>> .jdbc >>>>>>>>> .datasource >>>>>>>>> .DataSourceUtils.doGetConnection(DataSourceUtils.java:113) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .springframework >>>>>>>>> .jdbc >>>>>>>>> .datasource >>>>>>>>> .DataSourceUtils.getConnection(DataSourceUtils.java:79) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .springframework >>>>>>>>> .jdbc >>>>>>>>> .core >>>>>>>>> .support.JdbcDaoSupport.getConnection(JdbcDaoSupport.java:132) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .sakaiproject >>>>>>>>> .genericdao >>>>>>>>> .springjdbc >>>>>>>>> .JdbcGenericDao.commitTransaction(JdbcGenericDao.java:1057) >>>>>>>>> at >>>>>>>>> org.dspace.services.user.UserDAOTest.initDB(UserDAOTest.java: >>>>>>>>> 54) >>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> sun >>>>>>>>> .reflect >>>>>>>>> .NativeMethodAccessorImpl >>>>>>>>> .invoke(NativeMethodAccessorImpl.java:39) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> sun >>>>>>>>> .reflect >>>>>>>>> .DelegatingMethodAccessorImpl >>>>>>>>> .invoke(DelegatingMethodAccessorImpl.java:25) >>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:585) >>>>>>>>> at >>>>>>>>> >>>>>>>>> org >>>>>>>>> .junit >>>>>>>>> .internal.runners.ClassRoadie.runBefores(ClassRoadie.java:49) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .junit >>>>>>>>> .internal.runners.ClassRoadie.runProtected(ClassRoadie.java: >>>>>>>>> 36) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .junit >>>>>>>>> .internal >>>>>>>>> .runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .eclipse >>>>>>>>> .jdt >>>>>>>>> .internal >>>>>>>>> .junit4 >>>>>>>>> .runner.JUnit4TestReference.run(JUnit4TestReference.java:45) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .eclipse >>>>>>>>> .jdt >>>>>>>>> .internal.junit.runner.TestExecution.run(TestExecution.java: >>>>>>>>> 38) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .eclipse >>>>>>>>> .jdt >>>>>>>>> .internal >>>>>>>>> .junit >>>>>>>>> .runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .eclipse >>>>>>>>> .jdt >>>>>>>>> .internal >>>>>>>>> .junit >>>>>>>>> .runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .eclipse >>>>>>>>> .jdt >>>>>>>>> .internal >>>>>>>>> .junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org >>>>>>>>> .eclipse >>>>>>>>> .jdt >>>>>>>>> .internal >>>>>>>>> .junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) >>>>>>>>> INFO Destroying connection (2rvxw07xvtfzzt13e7k5w|d47c65): >>>>>>>>> org.apache.derby.impl.jdbc.EmbedConnection30@10970704 (XID = >>>>>>>>> 144), >>>>>>>>> (SESSIONID = 1), (DATABASE = DSpaceDerby), (DRDAID = null) >>>>>>>>> [2008-11-06 16:39:58,815] (DSpace >>>>>>>>> TestingConnectionCustomizer.java:41) >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Aaron Zeckoski (aa...@vt...) >>>>>>> Senior Research Engineer - CARET - Cambridge University >>>>>>> [http://bugs.sakaiproject.org/confluence/display/~aaronz/] >>>>>>> Sakai Fellow - [http://aaronz-sakai.blogspot.com/] >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------- >>>>>>> This SF.Net email is sponsored by the Moblin Your Move >>>>>>> Developer's >>>>>>> challenge >>>>>>> Build the coolest Linux based applications with Moblin SDK & >>>>>>> win great >>>>>>> prizes >>>>>>> Grand prize is a trip for two to an Open Source event anywhere >>>>>>> in the >>>>>>> world >>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>>>> _______________________________________________ >>>>>>> c3p0-users mailing list >>>>>>> c3p...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/c3p0-users >>>>>> >>>>>> ~oo~ >>>>>> Steve Waldman >>>>>> swa...@mc... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Aaron Zeckoski (aa...@vt...) >>>>> Senior Research Engineer - CARET - Cambridge University >>>>> [http://bugs.sakaiproject.org/confluence/display/~aaronz/] >>>>> Sakai Fellow - [http://aaronz-sakai.blogspot.com/] >>>> >>>> ~oo~ >>>> Steve Waldman >>>> swa...@mc... >>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Aaron Zeckoski (aa...@vt...) >>> Senior Research Engineer - CARET - Cambridge University >>> [http://bugs.sakaiproject.org/confluence/display/~aaronz/] >>> Sakai Fellow - [http://aaronz-sakai.blogspot.com/] >> >> ~oo~ >> Steve Waldman >> swa...@mc... >> >> >> >> > > > > -- > Aaron Zeckoski (aa...@vt...) > Senior Research Engineer - CARET - Cambridge University > [http://bugs.sakaiproject.org/confluence/display/~aaronz/] > Sakai Fellow - [http://aaronz-sakai.blogspot.com/] ~oo~ Steve Waldman swa...@mc... |