Re: [naviserver-devel] read/write ns_config

[Zoran V. <zv...@ar...>]

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