Brian,
I would suggest a relatively simple test for when to use a thread or not: if
it is pure tcl code with no database access, network activity or loops which
might grow in size and you can guess it executes very quickly, it doesn't
need a thread, otherwise you are giving this scheduled proce
Hi Andrew,
Thanks for explaining why every scheduled proc should not necessarily
have its own thread. That makes sense to me. Still, it makes it hard to
guarantee a start-time for a job.
The AOLserver error log consistently showed one proc running for an
"excessive time" - it was one of my own, n
... this trick is not working. let's try something else
Marc Kalberer a écrit :
Hi,
I got the same prob. I'm currently testing a solution :
setting
ns_param connsperthread 30
in the {server} section.
Seems that the aol thread is "restart" when the limit is reach, ...
lets consider it as a wo
> This raises the question for me, should all scheduled procs be run in
> their own thread to avoid creating these kinds of problems where other
> procs get affected?
This really depends on how crucial it is that the proc actually run every
(say) 15 minutes. Something that sweeps a queue of messa
Hi,
I got the same prob. I'm currently testing a solution :
setting
ns_param connsperthread 30
in the {server} section.
Seems that the aol thread is "restart" when the limit is reach, ... lets
consider it as a work around for memory leaks.
I don't know yet if it work, but I'll keep you inform
On Fri, Jun 16, 2006 at 10:22:46AM +0100, Brian Fenton wrote:
> this is useful information. I do occasionally see these messages in the
> error log: "Warning: sched: excessive time taken by proc 8 (43
> seconds)", so I guess that's the behaviour you describe. And it explains
> So what are my opti
