Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v1076)
Subject: Re: DBCP deadlock
From: Marc Logemann <ml@logemann.org>
In-Reply-To: <4AFE734F.2020605@free.fr>
Date: Sat, 14 Nov 2009 10:40:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <13993D02-F170-49C6-815B-4A9C07C29D78@logemann.org>
References: <7818B6A2-A7FD-4DB5-AF54-7DDDD478A10A@logemann.org>
  <4AFBCFB9.2040501@free.fr>
 <75914213-6D25-4414-AD25-B4DDC80BC3AA@logemann.org>
 <f2e8eedf0911120113h67f07aafn126bd2b5c1b493c2@mail.gmail.com>
 <23A7C19C-0734-4A15-B207-F189574DBA2D@logemann.org>
 <4AFC068E.9010908@apache.org>
 <9F567EB0-2E9C-4533-B54F-96845A727481@logemann.org>
 <4AFC4256.60802@apache.org>
 <1DDFCD1B-35BC-484A-BDC3-F919FCCA7B07@logemann.org>
 <4AFC4DD0.60409@gmail.com>
 <D69E4E2B-5DEE-4AC0-A706-60F17922736F@logemann.org>
 <4AFC62C2.3050703@marine.rutgers.edu> <4AFE734F.2020605@free.fr>
To: "Commons Users List" <user@commons.apache.org>

Hi,

thanks. Great hint. I always checked the DB server but you really need =20=

to check to be sure whats going on.
Since i am on Mac OS X, i will need to use "lsof" though. Netstat on =20
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 =3D> will give you your java pid
>
> nice watch -n 1 'netstat -a|grep ESTABLISH|grep your_app_pid'
> =3D> will display your netstat every 1s.
>
> Regards,
> Cyrille
>
> Wm.A.Stafford a =E9crit :
>> Marc,
>> I used the following to track down a connection leak when using an =20=

>> older version of DBCP.  I have not used it with later versions but =20=

>> I believe some of the DBCP methods seen here have been removed.  =20
>> This method was called after each call to open() and we saw the =20
>> number of active connections just keep on growing.
>>
>>   public static String getConnectionPoolInfo( Dao dao){
>>       BasicDataSource ds =3D dao.getDataSource() ;
>>       String configInfo =3D "initialSize=3D" + ds.getInitialSize() + =
" =20
>> maxActive=3D" + ds.getMaxActive() + " maxIdle=3D" + ds.getMaxIdle() + =
" =20
>> minIdle=3D" + ds.getMinIdle() ;
>>       return  configInfo + "\nactive connections=3D" + =
ds.getNumActive=20
>> () + " idle connections=3D" + ds.getNumIdle() ;
>>   }
>>
>> hope this helps,
>> -=3Dbeeky
>>
>> Marc Logemann wrote:
>>>>>
>>>>> But in my view, connection leak means, i am not closing SQL =20
>>>>> connections
>>>>> (apart form the fact that i checked this) but then these =20
>>>>> connections
>>>>> would be "in use" by the pool and also "in use" by the the =20
>>>>> 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 =20
>>>> pool
>>>> by executing close() on them, DBCP considers them active, in use. =20=

>>>> If
>>>> they are never returned, pool capacity is leaked.
>>>
>>>
>>> THen it would be interesseting to know who is killing the server =20
>>> jobs on the i5 (IBM) machine if not the pool itself. I am quite =20
>>> sure that the DB2 on the i5 is not deleting connection jobs =20
>>> because it cant know if they are still needed. If DBCP is killing =20=

>>> them it should not think at the same time that they are active and =20=

>>> wait for a close() call.
>>>
>>> In my view, a typical connection leak has plenty of connections on =20=

>>> the DB side (and in the pool of course) which are open and which =20
>>> never get closed. This is a typical situation.
>>>
>>> I will replace DBCP with the other mentioned pool if pool1.4 =20
>>> doesnt solve it and if i really have a problem with closing =20
>>> connections and thus leaking, i would face the same problems with =20=

>>> C3P0 too.
>>>
>>> BTW is there a log level which i can use where DBCP prints out how =20=

>>> many connections he thinks are currently in use by the pool? I =20
>>> 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