Re: DBCP connections not in accordance with netstat output

2010-10-20 Thread Felix Schumacher
Hi Marc,

Am Mittwoch, den 20.10.2010, 00:54 +0200 schrieb Marc Wilmots:
 Hi List,
 
 I installed Lambda Probe to debug a problem that I'm having with a Liferay
 portal (5.1.2):
 
 Tomcat: 6.0.26 with dbcp
 JDK: 1.6.0_18
 DB: Oracle 10.2.0.4 (ojdbc14)
 RHEL 5.4 64Bits
 
 When launching a stress test with JMeter, Lambda Probe indicates that my
 connection pool (150 connections (I know..extremely high)) is out of free
 connections (150 Busy and Established). However, when I do a netstat, there
 are only 20-30 established connections to the database.
 
 I would rather believe netstat over Probe, however when Lambda Probe
 indicates that my pool is out of connections I noticed that the stress test
 is going extremely slow and several requests are failing because of a
 response time out (60secs). (The Tomcat connection pool (500 threads) gets
 filled as well)
Try generating thread-dumps when your tomcat is under that load. That
way you can see where you might have problems.

 
 Why could it be that Probe indicates 150 established connections and netstat
 only 20-30?
I think Probe differentiates between established (pooled) connections
and busy (currently in use) connections. Maybe the established
connections are lazy and have no direct connection to the database.
Haven't checked it, so they very well be in another state, like
abandoned and cut down by a firewall... Your best bet is to look at the
thread-dumps.

 According to the DBA, the DB is not stressed at all.
 
 As soon as the stress test stops, the pool recovers itself. Netstat and
 Lambda numbers (idle connections) are now exactly the same.
dbcp will shrink the pool to the desired minIdle settings when no new
connections are needed.

HTH
 Felix
 
 I know it's extremely (if not impossible) to indicate me what the problem
 might be. I just would like to know how I should proceed to investigate this
 problem, as I'm currently out of ideas.
 
 
 Thanks in advance!



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: DBCP connections not in accordance with netstat output

2010-10-20 Thread Phil Steitz

On 10/20/10 5:32 AM, Felix Schumacher wrote:

Hi Marc,

Am Mittwoch, den 20.10.2010, 00:54 +0200 schrieb Marc Wilmots:

Hi List,

I installed Lambda Probe to debug a problem that I'm having with a Liferay
portal (5.1.2):

Tomcat: 6.0.26 with dbcp
JDK: 1.6.0_18
DB: Oracle 10.2.0.4 (ojdbc14)
RHEL 5.4 64Bits

When launching a stress test with JMeter, Lambda Probe indicates that my
connection pool (150 connections (I know..extremely high)) is out of free
connections (150 Busy and Established). However, when I do a netstat, there
are only 20-30 established connections to the database.

I would rather believe netstat over Probe, however when Lambda Probe
indicates that my pool is out of connections I noticed that the stress test
is going extremely slow and several requests are failing because of a
response time out (60secs). (The Tomcat connection pool (500 threads) gets
filled as well)

Try generating thread-dumps when your tomcat is under that load. That
way you can see where you might have problems.



Why could it be that Probe indicates 150 established connections and netstat
only 20-30?

I think Probe differentiates between established (pooled) connections
and busy (currently in use) connections. Maybe the established
connections are lazy and have no direct connection to the database.
Haven't checked it, so they very well be in another state, like
abandoned and cut down by a firewall... Your best bet is to look at the
thread-dumps.


According to the DBA, the DB is not stressed at all.

As soon as the stress test stops, the pool recovers itself. Netstat and
Lambda numbers (idle connections) are now exactly the same.

dbcp will shrink the pool to the desired minIdle settings when no new
connections are needed.


You mean maxIdle.  If abandoned connection cleanup is enabled, 
that will also eventually run at configured intervals, closing 
abandoned connections if they are still physically open and updating 
pool counters to reflect recovery.


Can you post your full DBCP configuration?  Have you verified that 
your code is closing all connections that it borrows from the pool?


Phil


HTH
  Felix


I know it's extremely (if not impossible) to indicate me what the problem
might be. I just would like to know how I should proceed to investigate this
problem, as I'm currently out of ideas.


Thanks in advance!




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org