This is code we inherited. Basically it wraps ns_schedule_proc with a job scheduled, that ensures everything has been run, and schedules items that didn't to run again.
We could probably rewrite this code, but if there was an easy way to look up the thread id of all current threads, it would save us (quite a bit of) work. Jade Jade Rubick Director of Development TRUiST 120 Wall Street, 4th Floor New York, NY USA jrub...@truist.com +1 503 285 4963 +1 707 671 1333 fax www.truist.com The information contained in this email/document is confidential and may be legally privileged. Access to this mail/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Tue, Jun 2, 2009 at 6:28 PM, Sep Ng <thejackschm...@gmail.com> wrote: > Hello everyone, > > I would like to say first of all I appreciate all the thought and > ideas you've brought to the table. What I hope to achieve is to be > able produce a rudimentary load management. I will take a look at > ns_pools and see if I can lift anything from it. Tom, you are right > that AOLserver puts the thread id on the logs and maybe it is worth a > look. > > On Jun 3, 7:37 am, Tom Jackson <t...@rmadilo.com> wrote: > > This is an interesting topic, but I can't think of anything to be gained > > from a list of threads. Who cares that a thread exists? > > > > But if you are just concerned with threads, you can use ns_pools. All > > worker threads in AOLserver are in some named thread "pool". If you > > don't use threadpools, all requests, no matter how many virtual servers > > you use are handled by the "default" threadpool. A query using ns_pools > > can give you a current thread count. > > > > Also you should know that every ns_log (error log) line has information > > about the threadpool and the thread id and every error log has the > > process id "dot" thread id just after the timestamp. If you wrote a > > script to examine the last part of the log file, you could discover > > which threads were active. > > > > Personally I would abandon the use of a list of "living" threads as a > > measure of anything. When AOLserver goes dark threads usually don't go > > away. > > > > tom jackson > > > > > > > > On Tue, 2009-06-02 at 12:12 +0200, Gustaf Neumann wrote: > > > It certainly depends on what your application needs. > > > There is no principal problem obtaining the thread id > > > (eg. ns_thread id, ::thread::id). One could either > > > use the sketched approach and simply record whatever > > > the application needs, or ffone can to extend the > > > xotcl-request monitor to track this information as well. > > > > > just to get the information about running connection > > > threads from the xotcl-request-monitor, use > > > "throttle running". > > > > > best regards > > > -gustaf neumann > > > > > Sep Ng schrieb: > > > > Hi Gustav! > > > > > > Thanks for the info. I'm afraid xotcl-request-monitor may not be > good > > > > enough if I do not have the thread ids, although I guess I could > > > > rewrite it to work with what xotcl-request-monitor provides. > > > > > > I did not know of one such monitoring page on OpenACS. I will take a > > > > look and see what I can find. > > > > > > On Jun 2, 3:42 pm, Gustaf Neumann <neum...@wu.ac.at> wrote: > > > > > >> Sep Ng schrieb:> Is there a way in AOLserver to do live monitoring > on > > > > > >>> threads? We're sort of hoping to get info on what thread ids are > > > >>> running as of the moment on aolserver. > > > > > >> The xotcl-request-monitor watches running requests, > > > >> essentially via defining filters/traces for requsts and > > > >> using a monitor thread for keeping track of the > > > >> "starts" and "ends" of requests. If there are "starts" > > > >> recorded without "ends", it knows these requests are still > > > >> running in some threads. This approach does not depened > > > >> on ns_info, we use it on all our production sites. > > > > > >> Originally i had one version for pure aolserver and one for > > > >> OpenACS; since a while i just work on the OpenACS version > > > >> (which is available via the public cvs repository of > > > >> OpenACS). > > > > > >> best regards > > > >> -gustaf neumann > > > > > >> -- > > > >> AOLserver -http://www.aolserver.com/ > > > > > >> To Remove yourself from this list, simply send an email to < > lists...@listserv.aol.com> with the > > > >> body of "SIGNOFF AOLSERVER" in the email message. You can leave the > Subject: field of your email blank. > > > > > > -- > > > > AOLserver -http://www.aolserver.com/ > > > > > > To Remove yourself from this list, simply send an email to < > lists...@listserv.aol.com> with the > > > > body of "SIGNOFF AOLSERVER" in the email message. You can leave the > Subject: field of your email blank. > > > > > -- > > > AOLserver -http://www.aolserver.com/ > > > > > To Remove yourself from this list, simply send an email to < > lists...@listserv.aol.com> with the > > > body of "SIGNOFF AOLSERVER" in the email message. You can leave the > Subject: field of your email blank. > > > > -- > > AOLserver -http://www.aolserver.com/ > > > > To Remove yourself from this list, simply send an email to < > lists...@listserv.aol.com> with the > > body of "SIGNOFF AOLSERVER" in the email message. You can leave the > Subject: field of your email blank. > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to < > lists...@listserv.aol.com> with the > body of "SIGNOFF AOLSERVER" in the email message. You can leave the > Subject: field of your email blank. > -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <lists...@listserv.aol.com> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
