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.

Reply via email to