tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: IIS 6.0 / JK1.2.25 / Tomcat 5.5.20 - "Service temporary unavailable"
Date Thu, 03 Jul 2008 13:08:02 GMT
Hi Jesse,

Jesse Klaasse wrote:
> Hello Rainer,
> 
> Thanks again for your prompt and clear reply. You're helping me a lot!
> 
> I have implemented the settings as you suggested (for the datasources of all
> 8 webapps on my Tomcat server). I need to wait for a restart of the
> application before the settings become active, however.
> For your information: currently (Tomcat is running fine now) a netstat
> command returns about 30 established connections to the database server. I
> have lowered the removeAbandonedTimeout setting to 30 seconds instead of 60.

... and the 30 seconds are already active (restart done) or also only 
after the next restart ...

> I still have a few questions left;
> 
> Why are there no 'AbandonedObjectPool' messages at all when Tomcat is
> running fine? I would expect a slowly growing number of locked threads
> because of the AbandonedObjectPool. But this not happening. Does this maybe
> mean that once it goes wrong, it skyrockets up to the total of 400 locked
> threads? And why would that be?

By message we mean methods in the thread stacks contained in a thread dump?

Usually getConnection() is a very fast method. So it will be hard to 
find a thread in there unless the getConnection() triggers a new 
connection establishment to the database (which again might only take a 
handful of milliseconds), or the pool is exhausted and getConnection() 
goes into the maxWait.

So yes, I would expect, that if one getConnection() hangs seriously, 
i.e. needs to wait long for actually getting a connection, then very 
soon a lot of threads will get into this state. Depending on your load, 
it's possible that e.g. you are calling getConnection() 100 times per 
second. So if the pool is full for a couple of seconds, you can quickly 
see the threads accumulating in this state.

What we don't know:

- why is the pool getting full?
- why is this situation persistent, i.e. it seems no more connections 
are freed.

The seconds point is the important one. I don't have a good explanation 
here, and checking with the commons mailing lists might be a good idea.

Of course a lot of dbcp users hang around on this list here. To get some 
feedback from them, maybe start a new thread with a more specific Subject.

> In the STDOUT logs of the past few days, there are no messages at all saying
> something like 'DBCP object created'. Shouldn't there be such messages
> already?

Yes, if you had logAbandoned="true" during that time, and dbcp detected 
any connections, which were not freed. Again: I have no convincing 
hypothesis what's happening, apart from the fact, that the solution lies 
in the subsytems webapp/DBCP/database.

> And finally, would you advise me to install the 1.2.26 version of the
> isapi_redirector connector again? As well as the 1.1.12 (or 1.1.13, but I
> can't find it for Win64) version of the APR?

1.2.26: first solve your db pool problem, at least until the situation 
gets stable. Updating to 1.2.26 is optimization and not critical. 
Concentrate on the pool first.

The same for tcnative 1.1.13 or the forthcoming 1.1.14 (I guess that 
will be announced soon).

> Thanks. Jesse.

Regards,

Rainer

> Rainer Jung-3 wrote:
>> 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.
>>


-- 
kippdata
informationstechnologie GmbH   Tel: 0228 98549 -0
Bornheimer Str. 33a            Fax: 0228 98549 -50
53111 Bonn                     www.kippdata.de

HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann
===============================
kippdata
informationstechnologie GmbH   Tel: +49 228 98549 -0
Bornheimer Str. 33a            Fax: +49 228 98549 -50
D-53111 Bonn                   www.kippdata.de

HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message