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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
