commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Logemann ...@logemann.org>
Subject Re: DBCP deadlock
Date Sat, 14 Nov 2009 09:40:34 GMT
Hi,

thanks. Great hint. I always checked the DB server but you really need  
to check to be sure whats going on.
Since i am on Mac OS X, i will need to use "lsof" though. Netstat on  
BSD is not as powerfull as on linux.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 14.11.2009 um 10:07 schrieb cyrille free:

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


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


Mime
View raw message