commons-user mailing list archives

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

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.

Regards,
Cyrille

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: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message