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


(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.


AOLserver -

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.

Reply via email to