The error catching concept is definitely wise. In fact I'll go ahead and put those in. This code is sort of legacy and old but it's definitely worth revising it.
The reason I don't see this might be the source of the issue, is that the same thing works (and is been working) with the older version of AOLserver which we have been using for years. Although there might be another hole or a different config that is causing the ns_muext to show up as the problem.
Regarding the error handling in this code, as you see, the only thing is between the lock/unlock block is just incrementing the arrays, and also the database action takes places after unlocking. Since the existence of the arrays also is being tested and takes place before attempting to use ns_mutex, I'm assuming that no error could cause the ns_mutex unlock to be skipped because of an exception, plus nothing shows up in the error log either.
These being said, still I'll try to put a catch block anywhere between the ns_mutex lock/unlock, blocks in the code.
I'd also like to try Nathan's mutexmeter solution to see if I find anything new.
Thanks for the advices,
Seena
-----Original Message-----
From: Andrew Piskorski [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 27, 2003 2:06 PM
To: [EMAIL PROTECTED]
Subject: Re: [AOLSERVER] ns_mutex is likely causing our AOL web server
to hung
On Mon, Jan 27, 2003 at 12:23:50PM -0600, Rob Mayoff wrote:
> So the next logical step (other than creating a test case) is to test
> the hypothesis that such is the case, by putting catch commands around
> your critical sections. For example, suppose the critical section looks
> like this:
>
> ns_mutex lock L
> SCRIPT
> ns_mutex unlock L
>
> Then you should change that to this:
>
> ns_mutex lock L
> set code [catch {
> SCRIPT
> } result]
> ns_mutex unlock L
This is good advice, and not just for debugging! When I run ANY with
a mutex locked that could ever possibly error out, I always wrap it in
a catch to properly clean up the mutex on error. E.g.:
ns_mutex lock $data_mutex
if { [catch {
error "Foo!"
} errmsg] } {
# We caught an unexpected error while the mutex was locked, so
# unlock the mutex, then re-throw the error:
ns_mutex unlock $data_mutex
global errorInfo
set my_error $errorInfo
error $my_error
}
ns_mutex unlock $data_mutex
--
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com
