On 24.08.2006, at 20:26, Stephen Deasey wrote:
That's because it's a bad idea... :-)
Ah, it is. The "original" idea is not though. I hate to reboot the server just to turn on or off a bit. We have a module doing SCSI communication. It can be turned on to make extended logging. This is controlled by a ns_config parameter. So, on customer site I might need to turn this in in the middle of the job. The processed some TB of data and got stucked, I need to find out why. The job ran for some 10's of hours (perhaps 2 or 3 days) and consumed about 10-15 tapes. Now I'd need to STOP the server, killing the job? No way. There has to be a better solution. Hence the need for changing in-memory config.
Maybe the limits stuff is a possible model. Unlike the aols4.5 version, the one is our cvs handles config by default in the standard fashion by looking up values in the config file. However, it does this from Tcl in tcl/limits.tcl. The limits code creates a new tool. The tricky stuff, the locking, is handled in C. The tool is presented as Tcl commands, and Tcl is used to configure it at start up. It looks just like any other server subsystem: ns_section "ns/limits" ns_param default "The default limits" ns_param restrict "A restricted set of limits" ns_section "ns/limits/default" ns_param maxrun 100 ns_param maxwait 100 ns_param maxupload [expr 10*1024*1000] ns_param timeout 60 ns_section "ns/limits/restrict" ... In the majority of cases, that's probably all that's needed. Config goes in the config file, not buried in some Tcl code. However! You can also, at runtime, call: ns_limits_set -maxrun 10 -timeout 30 -- restrict This is what you're trying to achieve with the read/write config. The defaults get set at start up, and then at runtime, you call ns_config_set and everything magicaly updates.
This MUST also internally lock, or? You can't have shared access w/o locking, or? Is this limits stuff yet another "specialized" thing like this config, which costed me so much hair pulling? If yes, then we should avoid using it at any cost!
The tool based approach is more flexible though. You could, if you wanted, have a very minimal config file to bootstrap the server and config everything yourself, getting the values from an HTTP server (as someone mentioned), from a local SQLite db, whatever you can dream up. A tool based approach also fits in better as a stand alone Tcl module. There's usually not 'config' file when you 'package require' a module.
The tool-based approach is exactly what? Is that something like ns_ictl or ns_logctl where you have an extra configurator command? If yes, then yes, I understand this. This is perhaps better way to go. It is more logical and versatile than the config stuff. To treat the config as a big "default" seems logical in this light.
Anyway, the idea is that maybe forcing everything to go through the config system is too restricting, and that the config, as it stands, is a great *default*. And recognising that the locking requirements can be very different for different subsystems. Some config options are dependant on others. A change in some should initiate an action, such as purge a cache down to it's new maximum size.
Yes.
Maybe what we need is to start moving more things to this model. For example, remove the calls to Ns_Config*() from nsd/log.c and instead use ns_logctl from within tcl/init.tcl etc. (move the limits stuff there).
Yes.
It may be the case that not all the logging options can be dynamically adjusted. That's OK, maybe they can be set via ns_logctl only at start up, which is a special single threaded environment. Perhaps there's some helper functions we can add that would make writing config functions easier, in the way that Ns_ParseObjv() makes parsing options easier. Seems like there's a whole bunch of manual twiddling going on in nsproxy/nsproxylib.c:ConfigureObjCmd() for example.
Ah... this is right. I will rewrite that. Old habits are difficult to handle!
Now, climb down off the balcony and have a nice cup of tea and a biscuit!
Only after I get a clear picture :-) But the hint with tool approach is a good way to look at. I will have to give it more thoughts. Thanks for the encouraging ideas! Cheers Zoran
