tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: IIS 6.0 / JK1.2.25 / Tomcat 5.5.20 - "Service temporary unavailable"
Date Thu, 03 Jul 2008 11:03:05 GMT
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=""
> 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

So maybe start with something like


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



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

View raw message