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
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
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 FORM name=newEmp method=post
action=
append return1 INPUT type='hidden' name='EMP_ID'
value=$empId
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
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
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
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
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
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
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
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
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
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,
+-- 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.
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
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.)
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
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 --
+-- 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
+-- 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
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
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
+-- 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
+-- 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.
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
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
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
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
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
29 matches
Mail list logo
