Michael,
I have just provided you with information which shows that even this is not
functioning correctly. If you have multiple virtual servers, whichever one
runs the pools.tcl file last will set the default pool parameters, and there
is only one 'default' pool in a single nsd process, no matter how many
virtual servers you have. So whatever pools.tcl is supposed to do or not do,
it looks like pools use a single hash table with the key being only the pool
name. Maybe this is the intent, although it would be easy to add the server
name to the key.
Also, please remember that the previous functionality allowed all pools to be
configured via the config file.
Given your opinion and Dossy's, which until today were never discussed on this
list, maybe the AOL team can discuss it a little. I haven't seen any evidence
that the proposed change is of any benefit, in fact we already have evidence
to the contrary. If this is the first experiment in how things will go, maybe
you should stop looking for documenters for broken code and ask for some real
design help.
Earlier today I was somewhat defending this as a simple oversight, but now it
is becoming obvious that you, Dossy and Nathan simply don't get it: you have
removed functionality and half replaced it with broken code. Who does this,
doesn't tell anyone for a year and then defends it with comments like "don't
upgrade if you don't like it". Even if you could move all this module
configuration into modules and packages, you still have to configure which
modules to load and a bunch of other stuff.
Yes, the configuration file sucks and is hard to make even slight improvements
in the way things work, and it doesn't usually contain default values set in
C code, but lets take a little look at my current setup, one small part:
server.tcl (virtual server configuration file)
#
# Module Configuation Files:
#
foreach {module lib} $ServerModules {
set moduleFile $configDir/${module}.tcl
if {[file exists $moduleFile]} {
source $moduleFile
}
}
Notice that each virtual server has its own config directory, on the same
level as the pages directory. Also, each module must have a unique name, so
files named after the module are guaranteed not to conflict with each other.
Also, each virtual server could have independent configuration files for a
given module. But if you mix config files with code, then any differences
will require you to use separate copies of the module code, and it also makes
code versioning difficult.
The previous threadpools config was handled in a similar way:
#
# Thread Pools
#
set pools [list fast default-jnm]
foreach pool $pools {
set poolScript "$configDir/threadpool-${pool}.tcl"
if {[file exists $poolScript]} {
source $poolScript
}
}
and threadpool-fast.tcl contains this:
# Single Threadpool
# pool = fast
ns_section "ns/server/${server}/pools"
ns_param $pool "$pool pool"
ns_section "ns/server/${server}/pool/$pool"
ns_param maxconnections 100
ns_param minthreads 2 ;# default = 0
ns_param maxthreads 10
ns_param threadtimeout 120
ns_param map "GET /*-thumb.jpg"
ns_param map "GET /images/*-thumb.jpg"
ns_param map "GET /test.html"
The above threadpool configuration could just as easily go in with the module
configuration file so it is obvious what the threadpool is used for. But
another look at the maps above also demonstrates the logic failure of tying
threadpools to modules: some threadpools apply to an entire virtual server.
If static files can be served by a dedicated set of threadpools, then these
threads may avoid accumulating a lot of extra code and data, or long running
threads can be restricted to just a few instances server-wide.
Mamma said, "Stupid is as stupid does." This whole thing is done stupid.
tom jackson
On Wednesday 01 August 2007 20:35, Michael Andrews wrote:
> To clarify - The pools.tcl file I wrote serves ONE purpose. To set
> the "default" pool's params to what is in the server config. This
> was ONLY done because folks expected the default pool to be set at
> start up using the config params... as it was in 4.0.10.
>
> My opinion is that any OTHER pools should be created and managed by
> Tcl Modules and or Tcl Packages, not the server config.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
