commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cyrille free <>
Subject Re: DBCP deadlock
Date Sat, 14 Nov 2009 09:07:27 GMT

you can also use system to monitor your connections:

nice ps -ef|grep java => will give you your java pid

nice watch -n 1 'netstat -a|grep ESTABLISH|grep your_app_pid'
=> will display your netstat every 1s.


Wm.A.Stafford a écrit :
> Marc,
> I used the following to track down a connection leak when using an 
> older version of DBCP.  I have not used it with later versions but I 
> believe some of the DBCP methods seen here have been removed.  This 
> method was called after each call to open() and we saw the number of 
> active connections just keep on growing.
>    public static String getConnectionPoolInfo( Dao dao){
>        BasicDataSource ds = dao.getDataSource() ;
>        String configInfo = "initialSize=" + ds.getInitialSize() + " 
> maxActive=" + ds.getMaxActive() + " maxIdle=" + ds.getMaxIdle() + " 
> minIdle=" + ds.getMinIdle() ;
>        return  configInfo + "\nactive connections=" + 
> ds.getNumActive() + " idle connections=" + ds.getNumIdle() ;
>    }
> hope this helps,
> -=beeky
> Marc Logemann wrote:
>>>> But in my view, connection leak means, i am not closing SQL 
>>>> connections
>>>> (apart form the fact that i checked this) but then these connections
>>>> would be "in use" by the pool and also "in use" by the the server jobs
>>>> that hold the connections. But thats not the case.
>>> The "server jobs" may have vanished entirely, resulting in the
>>> connection wrappers that they checked out from the pool getting
>>> *abandoned*. Unless and until these objects are returned to the pool
>>> by executing close() on them, DBCP considers them active, in use. If
>>> they are never returned, pool capacity is leaked.
>> THen it would be interesseting to know who is killing the server jobs 
>> on the i5 (IBM) machine if not the pool itself. I am quite sure that 
>> the DB2 on the i5 is not deleting connection jobs because it cant 
>> know if they are still needed. If DBCP is killing them it should not 
>> think at the same time that they are active and wait for a close() call.
>> In my view, a typical connection leak has plenty of connections on 
>> the DB side (and in the pool of course) which are open and which 
>> never get closed. This is a typical situation.
>> I will replace DBCP with the other mentioned pool if pool1.4 doesnt 
>> solve it and if i really have a problem with closing connections and 
>> thus leaking, i would face the same problems with C3P0 too.
>> BTW is there a log level which i can use where DBCP prints out how 
>> many connections he thinks are currently in use by the pool? I mean, 
>> this would be a valuable information for debugging.
>> Marc
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message