Stan Kaufman wrote:
Which coincidentally is the expiry time (MaxOpen and MaxIdle) set on
my database connections. My system is ACS-derived, so I wouldn't be
surprised if these database settings are common in other ACS-derived
systems.
What do you think is the reason that not all systems encounter this 1B
second issue? The passage of time is the one factor inevitably shared by
every system running aolserver, yet not every system barfs in the same
fashion. Why?
Simple, because it's a config file setting, not anything to do with the
underlying system. If your config file has
[ns/db/pool/main]
MaxOpen=1000000000
MaxIdle=1000000000
(which I think was done to work around some ancient bug in an ancient
version of the nsoracle driver) then you get the problem. If your
timeouts are more reasonable or 0 to explicitly specify never timeout,
then no problem.
It took me longer than it should have to track down this problem, since
it was happenning immediately after the database connections were
started, and other servers with no database connections (like the
keepalive server) had no problems; we of course thought there was some
database issue but didn't think about looking at the settings or that
the unix daemon dogging your heels for removing that comment would stop
so soon (obscure humor there...)
I imagine on Linux it manifests differently; on Solaris I got the EINVAL
return from pthread_cond_timedwait (of course it isn't documented that
this can mean a bad time, it usually means a bad pointer) but on linux
with a different pthreads implementation it could result in locking up
or just never returning (which presumably would result in all timed
events after it in the queue which us sorted by time getting blocked and
not running, as others reported.
-J
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.