Title: RE: [AOLSERVER] ns_mutex is likely causing our AOL web server to hung - Memory problem
You are right Andrew, we are using ACS and I believe the version is 2.2.3. Now the info tclversion says 8.3, but the info patchlevel says 8.3.2, also the directory is aolserver/lib/tcl8.3/, so
away-n2-cs.log# archive
templatens_param ArchiveFile
/home/nsadmin/log/away/old-cs-logs/away4-cs-log
-Original Message-From: Seena Kasmai
[mailto:[EMAIL PROTECTED]]Sent: Monday, January 27, 2003 6:08
PMTo: [EMAIL PROTECTED]Subject: Re: [AOLSERVER]
ns_mutex is likely causing our AOL web se
ogs/away-n2-cs.log# archive
templatens_param ArchiveFile
/home/nsadmin/log/away/old-cs-logs/away4-cs-log
-Original Message-From: Seena Kasmai
[mailto:[EMAIL PROTECTED]]Sent: Monday, January 27, 2003 6:08
PMTo: [EMAIL PROTECTED]Subject: Re:
[AOLSERVER] ns_mu
On Thursday, January 30, 2003, at 07:58 PM, Seena Kasmai wrote:
Would some please be kind enough and assist me how to only upgrade my TCL
to 8.3.1 from my AOLserver/3.3.1+ad13 w/TCL 8.3 ??
For versions of AOLserver prior to 3.5, the Tcl implementation was tightly
tied to the AOLserver, and the
Title: RE: [AOLSERVER] ns_mutex is likely causing our AOL web server to hung - Memory problem
Well, the strange thing is we never see such a behavior on 2.3.3 w/TCL 7.0, and we run 4 web server with the same code/application. That's why I can't think of any code related issue.
I did check
In a message dated 1/30/03 9:27:18 PM, [EMAIL PROTECTED] writes:
Anyhow, would you recommend to upgrade to 3.4.2 or 3.5.1 w/ TCL 8.3.1 ?
3.5.x is Tcl 8.4.x only. I'd recommend upgrading to 3.5 if you're going to try and upgrade. It will put you in a good position to move to 4.0 once it gets
On Thursday, January 30, 2003, at 09:19 PM, Seena Kasmai wrote:
Well, the strange thing is we never see such a behavior on 2.3.3 w/TCL 7.
0, and we run 4 web server with the same code/application. That's why I
can't think of any code related issue.
It's been a long time since I've used 2.3.3,
Title: RE: [AOLSERVER] ns_mutex is likely causing our AOL web server to hung - Memory problem
With 2.3.3 we use ACS and we use Oracle. Everything in the application seems to be working fine and we heavily tested all parts of the site, we don't see any Error or failure when the server starts
On Thu, Jan 30, 2003 at 07:58:55PM -0500, Seena Kasmai wrote:
Would some please be kind enough and assist me how to only upgrade my TCL to
8.3.1 from my AOLserver/3.3.1+ad13 w/TCL 8.3 ??
3.3+ad13 ships with Tcl 8.3.2. You can verify this. If you compiled
from source, look for the directory
On Thu, Jan 30, 2003 at 09:41:27PM -0500, Seena Kasmai wrote:
With 2.3.3 we use ACS and we use Oracle. Everything in the application seems
We sort of have our own version of ACS (we have added/modified it), given
it's functioning with 3.3.1, is it possible to upgrade to 3.5.1 w/ TCL 8.4 ?
Hey
Nathan!
Hereis
the simplified version of the code which shows how we are using ns_mutex in our
application. Basically the proc A, is being called a lot( more than 100
times in a minute) across the applications, and proc B is scheduled to run every
~5 minutes. Here the primary reason for
Put catches around your locked code and you may find a bug, for example,
incrementing an array var that doesn't exist or unsetting an array var
that doesn't exist. Without ns_mutex calls, the code may blow up but
your server won't lock up.
Jim
This message is in MIME format. Since your mail
In a message dated 1/27/2003 11:21:51 AM Eastern Standard Time, [EMAIL PROTECTED] writes:
proc_doc Y {} {
ns_share counter_A
ns_share counter_B
ns_share counter_mutex
ns_mutex lock $counter_mutex
foreach i_index [array names counter_A] {
set temp_counter_A($i_index)
Title: RE: [AOLSERVER] ns_mutex is likely causing our AOL web server to hung
Good point, but there are logics before these lines (I have take out, the actual code is couple pages but is pre-processing stuff and error checking) that takes care of the errors.
I don't think exception/error
In a message dated 1/27/2003 10:43:28 AM Central Standard Time, [EMAIL PROTECTED] writes:
foreach i_index [array names counter_A] {
set temp_counter_A($i_index) $conter_A($i_index)
set temp_counter_B($i_index) $conter_B($i_index)
unset $conter_A($i_index)
unset $conter_B($i_index)
}
Is
sorry,
there is no $ sign in the actual code.
So, is
it worth trying to substitute ns_share with nvs stuff (nsv_set nsv_get) to see if the problem goes away
?
Thanks,
Seena
-Original Message-From: Michael Richman
[mailto:[EMAIL PROTECTED]]Sent: Monday, January 27, 2003 11:50
On Mon, Jan 27, 2003 at 12:25:32PM -0500, Seena Kasmai wrote:
So, is it worth trying to substitute ns_share with nvs stuff (nsv_set
nsv_get) to see if the problem goes away ?
Yes! With AOLserver 3.x or 4.x, you should always be using nsv
instead of ns_share if you can.
--
Andrew Piskorski
+-- On Jan 27, Seena Kasmai said:
sorry, there is no $ sign in the actual code.
So, is it worth trying to substitute ns_share with nvs stuff (nsv_set
nsv_get) to see if the problem goes away ?
Your most effective action, if you want to maximize the utility of
the advice from this
In a message dated 1/27/2003 12:32:51 PM Eastern Standard Time, [EMAIL PROTECTED] writes:
sorry, there is no $ sign in the actual code.
So, is it worth trying to substitute ns_share with nvs stuff (nsv_set nsv_get) to see if the problem goes away ?
Thanks,
Seena
I would definitly recommend
Title: RE: [AOLSERVER] ns_mutex is likely causing our AOL web server to hung
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
In a message dated 1/27/2003 2:22:09 PM Eastern Standard Time, [EMAIL PROTECTED] writes:
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
Nathan
- If you look at the code it does lock before attempting to any manipulation to
that array.
# ns_share counter_Ans_share counter_Bns_share -init
{ set counter_mutex [ns_mutex create] }
counter_mutex proc X {i} {
ns_share counter_Ans_share
In a message dated 1/27/2003 6:15:50 PM Eastern Standard Time, [EMAIL PROTECTED] writes:
Nathan - If you look at the code it does lock before attempting to any manipulation to that array.
Just making sure. ;-) Any luck with the nsv_incr approach or any more data from a server running with mutex
23 matches
Mail list logo
