Jesse Klaasse wrote:
Hi Rainer. Thank you very much for this preliminary information. I had
already noticed the AbandonedObjectPool messages myself.
My resource configuration:
name="bam/jdbc/vip8db"
auth="Container"
type="javax.sql.DataSource"
username="***REMOVED***"
password="***REMOVED***"
driverClassName="com.microsoft.jdbc.sqlserver.SQLServerDriver"
url="jdbc:microsoft:sqlserver://***REMOVED***;databasename=***REMOVED***"
removeAbandoned="true"
removeAbandonedTimeout="60"
logAbandoned="true"
validationQuery = "SELECT Bedrijfscode FROM entBedrijf"
I have already checked the Java code of the first 4 or 5 waiting threads,
but all connections/statement/resultsets are correctly closed. So the
problem seems to be in the dbcp, as you already say. But I'm not sure yet.
Would there be some kind of quick fix for now? To prevent Tomcat from
hanging? Although of course I'd prefer a real solution..
TC 5.5.20 seems to use dbcp 1.2.1 and commons-pool 1.2.
The things I remembered are more deadlock type problems, which do not
apply to your situation.
From the point of view of dbcp, the pool is exhausted, and
getConnection() hangs until a connection is returned to the pool.
You can set a maxWait value in order to make the hanging getConnection()
give up after some time. This will keep your app from blocking Tomcat,
but as long as no connections are given back to the pool, all requests
needing the database will result in errors. Also: if it is high load,
let's say 100 requests a second which need the database, and you set
maxWait to 5 seconds, then you would nevertheless end up with 500
threads waiting for a connection(), more than you have.
You haven't set a pool size. Look at
http://commons.apache.org/dbcp/configuration.html
So maybe start with something like
initialSize="10"
maxActive="50"
maxIdle"10"
minIdle="0"
maxWait="5000"
and check via netstat, how many connections you actually use during peak
load. Make sure, your database is correctly configured to handle the
maxActive connections.
Then lowering the removeAbandonedTimeout would help, if the feature
would find connections the app forgot to close, but maybe not soon
enough to cope with the demand on getConnection().
If abandoned connections are found, dbcp with logAbandoned enabled will
write to STDOUT messages like
DBCP object created... by the following code was never closed:
and then a code stack. You should check for those.
I'm not to optimistic about dbcp and pool updates, but of course you can
try. There is a deadlock potential though, see
https://issues.apache.org/jira/browse/DBCP-270
Regards,
Rainer
Thank you very very much for your work so far. I hope we will get to the
solution!
Jesse.
Rainer Jung-3 wrote:
The root problem lies within the database connection pool. All 400
Tomcat threads are waiting in getConnection() to get a free DB
connection from the common-dbcp pool.
There are some bugs around dbcp, but I need a little time to check, if
they apply to your version. This is just a short note, that yes, there
is some hope ;)
In the meantime: could you post your DataSource configuration (omit the
password).
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
