Reuven, the problem is probably not with AOLserver at all, but with
the hackery OpenACS does to implement watches on those .tcl files.
That's the place to start looking anyway.
What are your maxthreads, minthreads, and threadtimeout settings on
that server?
Did you, maybe, turn on PerformanceModeP sometime during that week?
That might well kill all file watching for any new threads created.
Actually, if changing the PerformanceModeP flag (to either on or off)
is obeyed at anything other than server start time, it would probably
give you weird and nasty results - old threads would have the latest
watched files, new threads would have older Tcl procs without the
watched files.
If I remember correctly, the watched files stuff never changes the
contents of the AOLserver master thread (or whatever it's called) at
all, as that thread is written to only during AOLserver startup. When
a new thread is spawned, AOLserver copies the master thread to the new
thread. The OpenACS file watching stuff roughly does two things: One,
it sources all the watched files into all existing threads. Two,
after each new AOLserver thread is spawned, it sources the watched
files into those threads too. Naturally these extra steps make thread
spawning less efficient.
I'd never purposely leave a server running for a week with watched
files, btw. I believe the whole file watching business was intended
strictly as a development tool. If it's a Development server, I would
simply restart the server every time I finish testing something and
commit the code to CVS. A Production server probably shouldn't ever
use watched files at all.
Oh yeah, and from the mailing list, it sounds like there's some last
minute work going into AOLserver 4.0 to give us lazy loading of Tcl
procs there. They're doing it in order to speed up start time of
AOLservers with really large amounts of Tcl code, but it may end up
giving us better tools for implementing stuff like the OpenACS file
watching as well.
