Re: [c3p0-users] Running out of connections?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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/]