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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
