Hi Rainer, We are a week later now, with the changed settings, and while the environment first seemed to be a little more stable, in the end this unfortunately is not the case... We still reboot Tomcat every night automatically, and most of the time once a day manually because of the 503 error.
For example, I restarted Tomcat and IIS 10 minutes ago, and in the last 10 minutes, isapi_redirect.log shows about 7 503 errors. Also a lot of 53, 54, 60 and 61 errors. Still looking into the dbcp issue.. I will try to put up a new post, but I'm not sure what the relevant info would be.. Do you have any clues left? Regards, Jesse. Rainer Jung-3 wrote: > > 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] > > > -- View this message in context: http://www.nabble.com/IIS-6.0---JK1.2.25---Tomcat-5.5.20---%22Service-temporary-unavailable%22-tp18238896p18379179.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
