Re: [AOLSERVER] POST of binary data

[Adam Zell]

Hello,

> Do the RFC's allow POSTing binary data using a content type of anything but
> multipart/form-data?  Looking at RFC 2616 at the moment, I see nothing that
> makes the answer clear.
>
As far as I am aware, it is accepted practice to send any type of data in
a POST, as long as it is url-encoded.  This is why I would like to re-do
Ns_Set to support arbitrary strings, not C strings (bug #458929).

> If ns_getform sees something that is not multipart/form-data, it collects
> using ns_conn form.  It seems that ns_conn form calls
> conn.c/ns_conngetquery which begets ns_querytoset which begets
> Ns_DecodeUrlCharset which looks for a NULL to determine the end of a string.
>
> So it appears that form.tcl/ns_getform (and hence AOLserver) requires
> binary data to be sent as multipart/formdata, but I am curious about the
> RFCs.  There appear to be certain applications that post binary data using
> other content types, are those applications broken, or is it AOLserver itself?
>
I would vote that AOLserver is broken.

Adam
[EMAIL PROTECTED]

> Thanks,
>
>
> Jerry
> 
> Jerry Asher  [EMAIL PROTECTED]
> 1678 Shattuck Avenue Suite 161   Tel: (510) 549-2980
> Berkeley, CA 94709   Fax: (877) 311-8688
>

Re: [AOLSERVER] POST of binary data

[Lee Teague]

> You can get the POST data into a file using ns_conncptofp.

Speaking of ns_conncptofp, does anyone know anything about ns_conn
content?  From what I understand, it's supposed to retrieve the content of
the POST (same as ns_conncptofp) except return a string rather than
writing a file.

ns_conn content returns:

unknown command "content": should be authpassword, authuser, ...,
content, ..., ...,

Seems like they intended to add in the content command, but neglected to
at the last minute.

Is it going to be in AOLserver 4?

--
Lee Teague
Placemark Investments
972.404.8100x31  |  [EMAIL PROTECTED]

Re: [AOLSERVER] POST of binary data

[Rob Mayoff]

+-- On Sep 20, Jerry Asher said:
> To do this though, am I right in thinking a script must not get call
> ns_getform unless the POST is multipart/form-data OR urlencoded?

If you want to call ns_conncptofp, you cannot call ns_getform at all -
either before or after calling ns_conncptofp.

Re: [AOLSERVER] POST of binary data

[Jerry Asher]

>The standard content-types for query data are multipart/form-data and
>application/x-www-form-urlencoded.  What content type are you seeing?

I am not sure the content type, this is following up a bug report to nsvhr
(suggesting that nsvhr didn't work with binary posts), but I know the
problem is not nsvhr's and I was just getting a bit further into what the
actual problem might be.

>You can get the POST data into a file using ns_conncptofp.  Then, using
>Tcl 8, you can examine the file and deal with any binary data.

To do this though, am I right in thinking a script must not get call
ns_getform unless the POST is multipart/form-data OR urlencoded?


Jerry





Jerry Asher  [EMAIL PROTECTED]
1678 Shattuck Avenue Suite 161   Tel: (510) 549-2980
Berkeley, CA 94709   Fax: (877) 311-8688

Re: [AOLSERVER] POST of binary data

[Rob Mayoff]

+-- On Sep 20, Jerry Asher said:
> So it appears that form.tcl/ns_getform (and hence AOLserver) requires
> binary data to be sent as multipart/formdata, but I am curious about the
> RFCs.  There appear to be certain applications that post binary data using
> other content types, are those applications broken, or is it AOLserver itself?

The standard content-types for query data are multipart/form-data and
application/x-www-form-urlencoded.  What content type are you seeing?

You can get the POST data into a file using ns_conncptofp.  Then, using
Tcl 8, you can examine the file and deal with any binary data.

[AOLSERVER] POST of binary data

[Jerry Asher]

I'm a bit muddleheaded this morning.

Do the RFC's allow POSTing binary data using a content type of anything but
multipart/form-data?  Looking at RFC 2616 at the moment, I see nothing that
makes the answer clear.

If ns_getform sees something that is not multipart/form-data, it collects
using ns_conn form.  It seems that ns_conn form calls
conn.c/ns_conngetquery which begets ns_querytoset which begets
Ns_DecodeUrlCharset which looks for a NULL to determine the end of a string.

So it appears that form.tcl/ns_getform (and hence AOLserver) requires
binary data to be sent as multipart/formdata, but I am curious about the
RFCs.  There appear to be certain applications that post binary data using
other content types, are those applications broken, or is it AOLserver itself?

Thanks,


Jerry

Jerry Asher  [EMAIL PROTECTED]
1678 Shattuck Avenue Suite 161   Tel: (510) 549-2980
Berkeley, CA 94709   Fax: (877) 311-8688

[AOLSERVER] Reminder: AOLserver weekly chat today

[mayoff]

The AOLserver weekly chat takes place today, 2001-09-20, and every
Thursday. Common topics include AOLserver, Tcl, SQL, ACS, and general
web-related questions.

The place: AIM chatroom "AOLserver" on exchange 4
The time: 20:00 UTC

During the summer, that time is
4 PM US/Eastern
3 PM US/Central
2 PM US/Mountain
1 PM US/Pacific

During the winter, that time is
3 PM US/Eastern
2 PM US/Central
1 PM US/Mountain
Noon US/Pacific

The URL for the chat room:

aim:GoChat?RoomName=AOLserver

Note: you do NOT need to be an AOL subscriber to access the chat room.

If you need more help getting on AIM or getting into the chat room,
please see .

--
end of message

Re: [AOLSERVER] AOLserver operational issues

[Rob Mayoff]

+-- On Sep 20, Peter M. Jansson said:
> I thought the interp kept data in the keys of the pthread, so I didn't
> think interps could migrate across threads -- I thought this was why
> AOLserver didn't keep the thread pool model.

Tcl keeps a small amount of data in thread-local storage, but I think
it's safe to let an interp migrate across threads.

Re: [AOLSERVER] AOLserver operational issues

[Zoran Vasiljevic]

On Thursday 20 September 2001 18:57, you wrote:
>
> You can hand off an interp to another thread.  You simply cannot have
> two threads using a single interp simultaneously.

Can you? AFAIK, there are interp-specific things stored
in various TSD areas, like exit handlers, events...

Re: [AOLSERVER] AOLserver operational issues

[Peter M. Jansson]

I thought the interp kept data in the keys of the pthread, so I didn't
think interps could migrate across threads -- I thought this was why
AOLserver didn't keep the thread pool model.

On Thursday, September 20, 2001, at 12:57 PM, Rob Mayoff wrote:

> +-- On Sep 20, Peter M. Jansson said:
>> My mistake.  As far as I know, though, Tcl 8.x precludes handing an
>> interp
>> off to another thread, so sharing interps among threads isn't possible,
>> right?
>
> You can hand off an interp to another thread.  You simply cannot have
> two threads using a single interp simultaneously.

Re: [AOLSERVER] AOLserver operational issues

[Rob Mayoff]

+-- On Sep 20, Peter M. Jansson said:
> My mistake.  As far as I know, though, Tcl 8.x precludes handing an interp
> off to another thread, so sharing interps among threads isn't possible,
> right?

You can hand off an interp to another thread.  You simply cannot have
two threads using a single interp simultaneously.

Re: [AOLSERVER] AOLserver operational issues

[Jim Wilcoxson]

Rob amazes me sometimes. :)  Someone posts an idea and Rob posts a complete
implementation the same day!  Very cool.

Jim

>
> Rob, thanks for fixing my simplistic solutions.  I'm woefully ignorant of
> namespaces, and your suggestion about how to handle filters and registered
> procs is excellent -- I hadn't thought this through that far yet.  (Poor
> Jim would probably have hit these things without your advice.)
>

Re: [AOLSERVER] AOLserver operational issues

[Peter M. Jansson]

On Thursday, September 20, 2001, at 12:56 PM, Jerry Asher wrote:

> I don't know how big an interp is
I'm not assuming the interp itself is very large.  I'd be willing to bet
it's a reasonably-sized data structure.  My guess is the other stuff we're
dragging along with the interp.

>  you could precreate more interps than threads
I don't think you can do this, because I believe Tcl 8.x requires an
interp be created and used exclusively by the same thread.

Re: [AOLSERVER] AOLserver operational issues

[Peter M. Jansson]

Rob, thanks for fixing my simplistic solutions.  I'm woefully ignorant of
namespaces, and your suggestion about how to handle filters and registered
procs is excellent -- I hadn't thought this through that far yet.  (Poor
Jim would probably have hit these things without your advice.)

Re: [AOLSERVER] AOLserver operational issues

[Jerry Asher]

>
>Your analysis seems spot-on to me.  I just thought this would be a quick
>hack to see if the tcl scripts are the culprit.  Even starting multiple
>threads at starting, you'll still take a hit if you have to crank up
>another thread during the life of the process.  I'm just trying to get a
>handle on likely avenues of attack for solutions.  Starting up a thread
>should be more heavyweight than forking a CGI, so I'm trying to get a
>handle on whether thread startup is heavy, and how, if at all, it can be
>mitigated.

I don't know how big an interp is, and I assume that anything that takes 3
seconds to init must be fairly large.  But if they are reasonably smallish
(though timeconsuming to init) you could precreate more interps than
threads, and then when new threads are created they will not have to under
go the interp start up penalty.


Jerry


Jerry Asher  [EMAIL PROTECTED]
1678 Shattuck Avenue Suite 161   Tel: (510) 549-2980
Berkeley, CA 94709   Fax: (877) 311-8688

Re: [AOLSERVER] AOLserver operational issues

[Peter M. Jansson]

My mistake.  As far as I know, though, Tcl 8.x precludes handing an interp
off to another thread, so sharing interps among threads isn't possible,
right?

On Thursday, September 20, 2001, at 12:46 PM, Rob Mayoff wrote:

> +-- On Sep 20, Peter M. Jansson said:
>> Tcl 8.x specifically requires that a thread
>> have no more than one interpreter,
>
> Tcl 8.x allows a thread to create as many interps as it wants.

Re: [AOLSERVER] AOLserver operational issues

[Peter M. Jansson]

On Thursday, September 20, 2001, at 12:40 PM, Jerry Asher wrote:

> So while you are certainly distributing that 2-3 second per interp startup
> cost over time, you aren't eliminating it.
>
[snip]
> I'm not saying what you guys want to do is wrong in any manner, I'm just
> trying to understand how AOLserver works and what applications rl_proc
> will
> be useful for.

Your analysis seems spot-on to me.  I just thought this would be a quick
hack to see if the tcl scripts are the culprit.  Even starting multiple
threads at starting, you'll still take a hit if you have to crank up
another thread during the life of the process.  I'm just trying to get a
handle on likely avenues of attack for solutions.  Starting up a thread
should be more heavyweight than forking a CGI, so I'm trying to get a
handle on whether thread startup is heavy, and how, if at all, it can be
mitigated.

Re: [AOLSERVER] AOLserver operational issues

[Rob Mayoff]

+-- On Sep 20, Peter M. Jansson said:
> Tcl 8.x specifically requires that a thread
> have no more than one interpreter,

Tcl 8.x allows a thread to create as many interps as it wants.

Re: [AOLSERVER] AOLserver operational issues

[Rob Mayoff]

+-- On Sep 20, Peter M. Jansson said:
> OK, I'm sorry to do this to you, but you seem to be the best candidate to
> be an experimental subject for this.  Can you make some changes to your
> Tcl libraries and report on the findings?  The changes I have in mind are
> as follows:
>
> - define a new command called "rl_proc", which takes three arguments, and
> is used instead of "proc" to define your commands.  In rl_proc, you would
> store the arg list and body in an nsv keyed by the proc name
>
> - define an unknown proc which consults the nsv for the command name, and
> if it's found, executes "proc" with the arg list and body from the nsv.
> If the proc is unknown, you can return an error

You must define the unknown command first, because library scripts can
call procs as well as define them.

You could just rename proc to _proc and then define a new proc:

proc unknown {args} {
set name [lindex $args 0]
if [nsv_exists procs $name] {
eval _proc [nsv_get procs $name]
uplevel 1 $args
} else {
uplevel 1 _unknown $args
}
}

rename proc _proc
_proc proc {name args body} {
nsv_set procs $name [list $name $args $body]
}

However, this will not handle namespaces correctly.  Anyway, I wouldn't
redefine the proc command.  I'd rather redefine the _ns_getnamespace
command, which is ultimately responsible for putting proc definitions
into the init script.

The _ns_getnamespace proc is defined in namespace.tcl. Put this in
zzz-last.tcl to make it load after namespace.tcl:

proc unknown {args} {
ns_log notice "unknown $args"
set name [lindex $args 0]
if {[string equal -length 2 :: $name]} {
if {[nsv_exists procs $name]} {
eval proc [nsv_get procs $name]
} else {
error "invalid command name \"$name\""
}
} else {
set ns [uplevel 1 {namespace current}]
if {$ns != "::" && [nsv_exists procs "${ns}::$name"]} {
eval proc [nsv_get procs "${ns}::$name"]
} elseif {[nsv_exists procs "::$name"]} {
eval proc [nsv_get procs "::$name"]
} else {
error "invalid command name \"$name\""
}
}

set code [catch {uplevel 1 $args} result]
return -code $code -errorcode $::errorCode -errorinfo $::errorInfo $result
}

rename _ns_getnamespace ""
proc _ns_getnamespace n {
ns_log notice "_ns_getnamespace $n"
namespace eval $n {
set n [namespace current]
set script ""
foreach v [info vars] {
switch $v {
n -
v -
script continue
default {
if [info exists ${n}::$v] {
if [array exists $v] {
append script [list variable $v]\n
append script [list array set $v [array get $v]]\n
} else {
append script [list variable $v [set $v]]\n
}
}
}
}
}
foreach p [info procs] {
if {$n == "::"} {
set np "::$p"
} else {
set np "${n}::$p"
}
set args ""
foreach a [info args $p] {
if [info default $p $a def] {
set a [list $a $def]
}
lappend args $a
}
if {$np == "::unknown"} {
append script [list proc $p $args [info body $p]]\n
} else {
nsv_set procs $np [list $np $args [info body $p]]
}
}
append script [concat namespace export [namespace export]]\n
return $script
}
}

There is another danger, though. The first time that nsd calls a
register proc or filter, it looks at the number of arguments that the
proc takes to decide whether to pass a connId argument. In this case,
nsd won't be able to determine the number of arguments, because the proc
isn't defined yet, so nsd assumes that it should NOT pass the connId
argument. This means that if you do this:

proc myfilter {conn args why} {
# whatever
}

ns_register_filter preauth GET /* myfilter

That you'll get an error on every request because nsd won't pass the
conn argument when it calls myfilter. You need to change the definition
of myfilter to not use the conn argument:

proc myfilter {args why} {
# whatever
}

ns_register_filter preauth GET /* myfilter

Re: [AOLSERVER] AOLserver operational issues

[Jerry Asher]

>
>In the absence of information about sharing compiled Tcl objects between
>interpreters, I can't see a way to address the memory footprint issue
>right now, but we could see if the thread startup issue helps in terms of
>time and maybe memory.

I came in on this late and missed the first posting, but won't hesitate
(sorry) to toss in my 2 cents.

If your plan works, wouldn't that to a great deal to address the memory
issues?  The "enormous string" will be shared in nsv form, and each interp
will only have those functions it uses.

On the other hand, assuming that:

1.  you only define functions that are used at sometime in your application
2.  your interps are never destroyed

I don't know if either of those are valid assumptions.  But regarding 2, a
quick examination of the code aolserver/nsd/tclinit.c, it doesn't appear to
me that interps are EVER destroyed UNLESS you specifically call
ns_markfordelete within your application or unless you call ns_eval in your
application and had ns_eval something that it bards on.

greps for markfordelete and for destroyinterp appear to reveal that nothing
in AOLserver ever deletes an interp.

So in the long run (but what is the long run), every interp will have every
function.

So while you are certainly distributing that 2-3 second per interp startup
cost over time, you aren't eliminating it.

If any of this is accurate, wouldn't another strategy just be to create a
reasonable number of threads in the beginning (using minthreads), or
creating a new parameter (mininterps) that precreates that many of interps
at startup?

I'm not saying what you guys want to do is wrong in any manner, I'm just
trying to understand how AOLserver works and what applications rl_proc will
be useful for.

Thanks,


Jerry


Jerry Asher  [EMAIL PROTECTED]
1678 Shattuck Avenue Suite 161   Tel: (510) 549-2980
Berkeley, CA 94709   Fax: (877) 311-8688

[AOLSERVER] Oracle + Aolserver 3.4 charset problems

[Toni Vila]

Hi,

We have recently upgraded our AOLserver 3.0 to AOLServer 3.4 due to the
Auth problem.

But now we notice some problems with some characters (accents), which on
the previous version did not appear.

In our Oracle 8.1.6 database, we have the following text: "Cerámica
Castellón", which should be "Cerámica Castellón".

In AOLServer v3.0, it was displayed on the web correctly ("Cerámica
Castellón"), but in AOLServer 3.4, it's just "Cerámica Castellón", and we
don't know how to translate it back to the correct charset.

It seems to me a Multibyte charset, as maybe Unicode, but although choosing
a ORA_NLS_LANG of "_.UTF8" or similar, it doesn't change anything.

I haven't changed any line in our configuration file, nor in the database
between versions.

Do you know what may have happened or how to correct it?

Regards,

Toni Vila

Re: [AOLSERVER] AOLserver operational issues

[Lamar Owen]

On Thursday 20 September 2001 12:07 pm, Lamar Owen wrote:
> In my current circumstance, I'd be running multiple nsd's under 3.x. A
> single 2.3.3 nsd handles, oh, about 15 IP addresses here, for our hosted
> sites as well as our internal sites.  We're not large enough to dedicate

Incomplete thought, there.  The thought should have been:
We're not large enough to dedicate a whole server machine to each hosted site
or pairs/quads of sites.  And AS 2.3.3 on a PPro 200 with 64MB can handle
15-20 virtual servers on a T1 with aplomb.  We did upgrade the hardware to an
AMD K6-2/500 w/ 256MB earlier this year -- and it just sits and runs happily.

And the Nimda menace didn't cause any problems -- even though we got hit
800,000 times thus far across our hosts.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Re: [AOLSERVER] AOLserver operational issues

[Lamar Owen]

On Thursday 20 September 2001 11:01 am, Peter M. Jansson wrote:
> On Thursday, September 20, 2001, at 10:53 AM, Lamar Owen wrote:
> > to stick with 2.3.3 here look more attractive  Of course, 2.3.3
> > had/has
> > its own problems, but this one is not one of them.

> If you run one or two web nsds per machine, you'll definitely win with
> AOLserver 3 or 4 -- it just works better, has fewer bugs, and Kriston won'
> t yell at you for using obsolete software.

In my current circumstance, I'd be running multiple nsd's under 3.x. A single
2.3.3 nsd handles, oh, about 15 IP addresses here, for our hosted sites as
well as our internal sites.  We're not large enough to dedicate

Due to the many changes from 2.3.3->3.0, 2.3.3 cannot fairly be called
obsolete, as it is still useful for many.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Re: [AOLSERVER] AOLserver operational issues

[Jim Wilcoxson]

Ok, I volunteer to be a guinea pig.  Maybe it will help spark my motivation
to get us running on 3.X; I have been dragging my feet because 2.3.3
basically works (although crashes several times/day).

We use this to redefine procedures:

# NOTE: next rename fails when file is sourced, 2nd rename fails
# on boot; this is correct
catch {rename ns_returnredirect aol_ns_returnredirect}
catch {rename ns_returnredirect {}}
rename rl_returnredirect ns_returnredirect

It works whether the file is sourced at boot time or after boot, saving
the current definition and making a new one.  Perhaps the same thing
could be done with proc so I don't have to edit everything??  Or I
can redefine it just for our library ... think I know how.

Jim

>
> On Thursday, September 20, 2001, at 10:39 AM, Jim Wilcoxson wrote:
>
> > I think the idea of redefining the unknown command is good.
>
> OK, I'm sorry to do this to you, but you seem to be the best candidate to
> be an experimental subject for this.  Can you make some changes to your
> Tcl libraries and report on the findings?  The changes I have in mind are
> as follows:
>
> - define a new command called "rl_proc", which takes three arguments, and
> is used instead of "proc" to define your commands.  In rl_proc, you would
> store the arg list and body in an nsv keyed by the proc name
>
> - define an unknown proc which consults the nsv for the command name, and
> if it's found, executes "proc" with the arg list and body from the nsv.
> If the proc is unknown, you can return an error
>
> This would allow you to simulate the dynamic proc definition without
> needing changes to AOLserver.  If you do this, let us all know if this
> makes a difference in thread startup times, and in overall performance,
> and if there's a positive change, we can try to attack any necessary
> changes in AOLserver.
>
> In the absence of information about sharing compiled Tcl objects between
> interpreters, I can't see a way to address the memory footprint issue
> right now, but we could see if the thread startup issue helps in terms of
> time and maybe memory.
>

Re: [AOLSERVER] AOLserver operational issues

[Peter M. Jansson]

On Thursday, September 20, 2001, at 10:53 AM, Lamar Owen wrote:

> My question is: how is AOLserver4 going to handle this?  Is AS4 going to
> throwback to 2.3.3's design in this for performance?  This makes our
> decision
> to stick with 2.3.3 here look more attractive  Of course, 2.3.3
> had/has
> its own problems, but this one is not one of them.

It's unlikely that AS4 will revert to the shared interpreter model.  Jim
Davidson hacked Tcl 7.x mightily to get it to allow interpreters to be
thread-safe and shareable.  Tcl 8.x specifically requires that a thread
have no more than one interpreter, and no interpreter can be shared across
threads; since AOLserver is moving to Tcl 8.x-only, the shared
interpreters are going away.

Still, that isn't all bad news -- the state maintained for an interpreter
isn't really large, rather the procs (compiled into objects) are the
biggest thing in memory (he writes without the benefit of actually
measuring), so there's hope.

If you run one or two web nsds per machine, you'll definitely win with
AOLserver 3 or 4 -- it just works better, has fewer bugs, and Kriston won'
t yell at you for using obsolete software.

Re: [AOLSERVER] AOLserver operational issues

[Lamar Owen]

On Thursday 20 September 2001 10:39 am, Jim Wilcoxson wrote:
> was happening.  I seem to recall thread startup being 2-3 seconds,
> which is an eternity compared to 2.3.3.

> With 2.3.3, we just bumped maxthreads whenever we were hitting that
> limit a few times a day.  With 3.X, we will have to keep in mind the
> long thread startup time and realize that most of the time it will be
> better for a new request to wait until another thread is finished
> rather than starting a new thread.

My question is: how is AOLserver4 going to handle this?  Is AS4 going to
throwback to 2.3.3's design in this for performance?  This makes our decision
to stick with 2.3.3 here look more attractive  Of course, 2.3.3 had/has
its own problems, but this one is not one of them.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Re: [AOLSERVER] AOLserver operational issues

[Peter M. Jansson]

On Thursday, September 20, 2001, at 10:39 AM, Jim Wilcoxson wrote:

> I think the idea of redefining the unknown command is good.

OK, I'm sorry to do this to you, but you seem to be the best candidate to
be an experimental subject for this.  Can you make some changes to your
Tcl libraries and report on the findings?  The changes I have in mind are
as follows:

- define a new command called "rl_proc", which takes three arguments, and
is used instead of "proc" to define your commands.  In rl_proc, you would
store the arg list and body in an nsv keyed by the proc name

- define an unknown proc which consults the nsv for the command name, and
if it's found, executes "proc" with the arg list and body from the nsv.
If the proc is unknown, you can return an error

This would allow you to simulate the dynamic proc definition without
needing changes to AOLserver.  If you do this, let us all know if this
makes a difference in thread startup times, and in overall performance,
and if there's a positive change, we can try to attack any necessary
changes in AOLserver.

In the absence of information about sharing compiled Tcl objects between
interpreters, I can't see a way to address the memory footprint issue
right now, but we could see if the thread startup issue helps in terms of
time and maybe memory.

Re: [AOLSERVER] AOLserver operational issues

[Jim Wilcoxson]

I ran some benchmarks about 6 months ago and saw very different
results when our TCL library was present vs. when it wasn't present.
We finally nailed the performance difference down to this thread
startup issue.  I don't remember the numbers, but it was striking
enough that I posted here about it and Rob (and others) explained what
was happening.  I seem to recall thread startup being 2-3 seconds,
which is an eternity compared to 2.3.3.

I think the idea of redefining the unknown command is good.  We have
something like 600 procs in our library.  On average, any given proc
may be used in only 5 places (I'm guessing here), so if a new thread
is launched, for us I believe it would be better to take the dynamic
proc definition hit rather than define 600 procedures.  I would guess
that a new thread would need fewer than 25 procs out of our library to
complete a random request.

It seems this setup would handle traffic spikes, web attacks, and
poorly-engineered search engine spiders much more smoothly.  In these
cases it is likely that a bunch of new threads will start to handle
the temporary load, service only a few requests, and then die (if
configured) after being idle a long time.  It would be a waste of
resources for all of these short-lived threads to know about our
entire library.  Taking the (small) dynamic proc hit 10-25 at a time
for each request would be much better, IMO, especially if a way
is devised to cache the compiled TCL using the same mechanism.

With 2.3.3, we just bumped maxthreads whenever we were hitting that
limit a few times a day.  With 3.X, we will have to keep in mind the
long thread startup time and realize that most of the time it will be
better for a new request to wait until another thread is finished
rather than starting a new thread.  We should only bump maxthreads
when the wait time starts to exceed 3 seconds.  (I have no idea how
we measure this yet...)

Jim

>
> On Thursday, September 20, 2001, at 09:46 AM, Jim Wilcoxson wrote:
>
> > Seems like some kind of dynamic proc definition mechanism similar to
> > autoloading would be useful here...
>
> I was just reading the Ousterhout book on the unknown command and
> autoloading.  I don't think the default Tcl autoloading mechanism is
> appropriate, because it depends on building an index file on disk, but I
> think it might be useful to create an AOLserver-specific unknown command,
> and perhaps redefine "proc" so that AOLserver stores the proc defs in a
> hash; then, when an unknown command is invoked, the AOLserver-specific
> unknown command could grab the def from the hash and eval it, and then
> execute the command.
>
> One issue I'm concerned about here is the overhead of such an approach --
> the first time through an interpreter, you could be hitting the unknown
> command a lot, and it could be really slow.  On the other hand, maybe it
> wouldn't be any slower than eval'ing a big script of all the procs.
>
> Jim, do you know if it's the interp startup script that's taking the time
> in your application?
>
> I was also thinking it would be useful if we could have some form of
> shared libraries for Tcl, so that a compiled proc could be shared among
> interpreters.  This would improve memory footprint, and might help reduce
> interp startup time.  Does anyone know if modern Tcl supports sharing
> compiled procs?  It didn't seem to as of 8.3, but I could be misreading
> the docs.
>

Re: [AOLSERVER] using javascript in TCL!!!

[Prakash Sinha]

Just keep in mind about quotes within quotes

set return1 ""

shud be

set return1 ""

but if u want to use ' instead of " u will be better off.

-Original Message-
From: AOLserver Discussion [mailto:[EMAIL PROTECTED]]On Behalf
Of deepti
Sent: Thursday, September 20, 2001 9:21 AM
To: [EMAIL PROTECTED]
Subject: [AOLSERVER] using javascript in TCL!!!


hello!
Is there anything wrong , if i wish to use javascript
in my TCL file like
described below.If i want to use all the client side
validation in this manner
,can i do?
thanx

set return1 ""
append return1 "
  
  function submitEmp() {

document.newEmp.submit()
  }
  
  "

__
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/

Re: [AOLSERVER] AOLserver operational issues

[Peter M. Jansson]

On Thursday, September 20, 2001, at 09:46 AM, Jim Wilcoxson wrote:

> Seems like some kind of dynamic proc definition mechanism similar to
> autoloading would be useful here...

I was just reading the Ousterhout book on the unknown command and
autoloading.  I don't think the default Tcl autoloading mechanism is
appropriate, because it depends on building an index file on disk, but I
think it might be useful to create an AOLserver-specific unknown command,
and perhaps redefine "proc" so that AOLserver stores the proc defs in a
hash; then, when an unknown command is invoked, the AOLserver-specific
unknown command could grab the def from the hash and eval it, and then
execute the command.

One issue I'm concerned about here is the overhead of such an approach --
the first time through an interpreter, you could be hitting the unknown
command a lot, and it could be really slow.  On the other hand, maybe it
wouldn't be any slower than eval'ing a big script of all the procs.

Jim, do you know if it's the interp startup script that's taking the time
in your application?

I was also thinking it would be useful if we could have some form of
shared libraries for Tcl, so that a compiled proc could be shared among
interpreters.  This would improve memory footprint, and might help reduce
interp startup time.  Does anyone know if modern Tcl supports sharing
compiled procs?  It didn't seem to as of 8.3, but I could be misreading
the docs.

Re: [AOLSERVER] using javascript in TCL!!!

[Jim Wilcoxson]

No, you can do this.  But you need to use \" for the quotes
inside a quoted string (like name=\"newEmp\") and if you
have dollar signs or braces inside the quotes and don't mean
to eval TCL variables or call TCL functions, you need to
backslash them too.

Also, a square function brace starts a new level of quotes, so:

   set xyz "Hi [callme "Jim W" "Fred X"] there"

is legal without the backslashes, but:

   set xyz "Hi [callme "Jim \"said\" this" "Fred X"] there"

would be needed to pass 2 arguments to callme:
arg1:   Jim "said" this
arg2:   Fred X

Jim

>
> hello!
> Is there anything wrong , if i wish to use javascript
> in my TCL file like
> described below.If i want to use all the client side
> validation in this manner
> ,can i do?
> thanx
>
> set return1 " action="">"
> append return1 " value=$empId>
>   
>   function submitEmp() {
>
> document.newEmp.submit()
>   }
>   
>   "
>
> __
> Terrorist Attacks on U.S. - How can you help?
> Donate cash, emergency relief information
> http://dailynews.yahoo.com/fc/US/Emergency_Information/
>

Re: [AOLSERVER] AOLserver operational issues

[Jim Wilcoxson]

My description was not accurate.  The TCL library is sourced once when
the server boots and all procedures and statements are executed.
During server startup, a huge string is created which contains the
proc statements for all of the procedures contained in your startup
directories.

Then whenever a new thread starts, this proc string is evaluated to
define all of the TCL procedures in the new thread; but nothing is
executed other than defining the procs.

Seems like some kind of dynamic proc definition mechanism similar to
autoloading would be useful here...

Jim

>
> Jim Wilcoxson wrote:
> >
> > Another circumstance is if you have a large TCL library code base in
> > modules/tcl and make heavy use of the thread mechanism, like frequently
> > starting detached threads.
> >
> > This is no big deal with 2.3.3 because of the shared TCL interpreter,
> > but 3.X takes a huge performance hit when a thread starts (and you have
> > a large TCL library).  Basically, your TCL library is sourced whenever
> > a thread starts in 3.x, but it is just "there" in 2.3.3.
>
> When you are saying "TCL library" are referring also at the tcl files in
>
> /usr/local/aolserver/servers/server1/modules/tcl ?
>
> because I have a lot of procedures there and also some startup commands
> that must be run only once for one AOL server (opening database and
> build a huge cache with information that need to be fetched almost
> instantly).
>
> Constantin Teodorescu
>

Re: [AOLSERVER] AOLserver operational issues

[Constantin Teodorescu]

Jim Wilcoxson wrote:
>
> Another circumstance is if you have a large TCL library code base in
> modules/tcl and make heavy use of the thread mechanism, like frequently
> starting detached threads.
>
> This is no big deal with 2.3.3 because of the shared TCL interpreter,
> but 3.X takes a huge performance hit when a thread starts (and you have
> a large TCL library).  Basically, your TCL library is sourced whenever
> a thread starts in 3.x, but it is just "there" in 2.3.3.

When you are saying "TCL library" are referring also at the tcl files in

/usr/local/aolserver/servers/server1/modules/tcl ?

because I have a lot of procedures there and also some startup commands
that must be run only once for one AOL server (opening database and
build a huge cache with information that need to be fetched almost
instantly).

Constantin Teodorescu

[AOLSERVER] using javascript in TCL!!!

[deepti]

hello!
Is there anything wrong , if i wish to use javascript
in my TCL file like
described below.If i want to use all the client side
validation in this manner
,can i do?
thanx

set return1 ""
append return1 "
  
  function submitEmp() {

document.newEmp.submit()
  }
  
  "

__
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/

Re: [AOLSERVER] AOLserver operational issues

[Jim Wilcoxson]

Another circumstance is if you have a large TCL library code base in
modules/tcl and make heavy use of the thread mechanism, like frequently
starting detached threads.

This is no big deal with 2.3.3 because of the shared TCL interpreter,
but 3.X takes a huge performance hit when a thread starts (and you have
a large TCL library).  Basically, your TCL library is sourced whenever
a thread starts in 3.x, but it is just "there" in 2.3.3.

Along those lines, I know there are minthreads and maxthreads settings.
Is there a setting that says "make sure you have at least N threads
available"?  Because of the high thread startup cost (it's seconds), I'd
rather our web visitors not have to wait while AS3 starts new threads
to process their request.

Jim

> There's one circumstance under which I'd recommend running AOLserver 2.3.3
> instead of AOLserver 3, and that's if you need to run a number of nsd
> processes.  AOLserver 3 can't scale to multiple nsds, because it is too
> bloated (in terms of resource usage).

Re: [AOLSERVER] AOLserver operational issues

[Peter M. Jansson]

There's one circumstance under which I'd recommend running AOLserver 2.3.3
instead of AOLserver 3, and that's if you need to run a number of nsd
processes.  AOLserver 3 can't scale to multiple nsds, because it is too
bloated (in terms of resource usage).  Unfortunately, AOLserver 2.3.3 has
a number of other issues that make it inferior to AOLserver 3.  Still, if
you need to run a number of nsds on one machine, and you can accept the
other limitations that come with AOLserver 2.3.3, it is a better choice
for you.

On Thu, 20 Sep 2001, Kriston wrote:
> The current trend in service calls to the AOLserver Support team concerns
> systems that have been crashing for mysterious reasons unrelated to the
> release of the server.  The common factors to all of these calls is that the
> machines had been changed to run 5 or more nsd processes per machine rather
> than just one or two.  It's important to consider that AOLserver will
> aggressively use the resources available to it and running multiple nsd
> processes carelessly will affect the performance of your machine.  This is
> due to resource limits in the operating system.  Let's be smart about this
> and if the occasion comes around where you want to run multiple nsd's per
> machine, please closely watch your system parameters.  Naturally, AOLserver
> will always effectively use *all* the processors on a multiprocessor
> machine, and starting up more than one nsd process should be considered with
> great care, study, and operational vigilence--something that is more
> detrimental than the predicted benefits might be.  Assuming that "everything
> was okay until now" does not count!  Especially since there has been some
> poor timing: increased load as a result of the Nimba worm, the increase of
> nsd processes per machine, and after-effects of current world events at the
> Pentagon and the Twin Towers.