thanks for you interest on the topic. my reply is below.
Warren Smith wrote:
> I haven't done any Webware development for quite some time and I never
> fully tested DbConnectionPool. However, this past weekend I was working
> on a Webware/Cheetah/PostgresSQL project and had some similar problems to
> yours on my development server, where Apache, Webware, and PostgresSQL are
> all running on the same machine (no firewall anywhere). Suspecting the
> database connection as the culprit, I tried adjusting the maxIdle and
> maxAge parameters of DbConnectionPool.startExpiration() to lower values
> than the defaults. So far, my problems have vanished. Perhaps I was
> running into a default timeout on the PostgresSQL connection itself?
so "bad" connections into DbConnectionPool can potentially
block the threads? this seems my problem too. after reviewing again
my log file i've spotted a request which caused a 404 response
to be generated by webware:
*** Starting request on thread Thread-9
346 2004-09-07 15:05:37 /it/index.py <--- this file does not exist
346 0.04 secs /it/index.py
*** Done with requ[est on thread Thread-9]
but note how Thread-9 didn't get stuck, probably
because webware didn't requested any connection from
the pool (no SitePage awake/sleep cycle), but simply redirected
user to its default 404 page (handleBadURL method).
> Just curious. Have you had any problems with DbConnectionPool? I knew a
> few people gave it a try back when I wrote it, but this is the first time
> that I have heard of someone still using it. Feedback, both positive and
> negative are still appreciated.
i've started using DbConnectionPool cause i have a firewall between
my dev win2k box and mysql running un linux, i was experiencing frequent
"lost connection to mysql" exceptions (not python-releated, i got those
error messages with MysqlCC GUI tool too). so i replaced
MiscUtils.DbPool with DbConnectionPool and problems went away. but on my
win2k i've no chance to test properly long-running processes and such
appserver lock-ups really manifest on the deploy machine.
> You may already realize this, but DbConnectionPool has no way of knowing
> if the connection that it has an internal reference to is really usable,
> so I'm not sure what you mean by 'resumes a "closed" connection'.
yes, my apologies, the phrase 'resumes a "closed" connection' does
not really describe what DbConnectionPool do.
i've not completely ruled out that the problems might be caused by the fact
i'm using a not threadsafe mysqlclient library. i'll hopefully move the
whole thing to a new linux server and see if it fixes the problem, but
at this time i'm pretty sure it's a database-related problem.
thanks for your time.