Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Dynamic Config

by mikkoi (Beadle)
on Dec 06, 2016 at 21:57 UTC ( [id://1177336]=perlquestion: print w/replies, xml ) Need Help??

mikkoi has asked for the wisdom of the Perl Monks concerning the following question:

cfg4j is a implementation of dynamic config, i.e. config can be changed while the program is running, and new values will replace the old values on-the-fly. Do we have anything like that? Should we? :-)

Replies are listed 'Best First'.
Re: Dynamic Config (meh)
by tye (Sage) on Dec 07, 2016 at 00:18 UTC

    Well, there is one claim from the documentation that probably serves as a primary motivation for the creation of the project:

    Being able to change your configuration without bringing the service down is extremely important for web apps.

    I don't find that to actually be true. Because a well-designed service sits behind some type of load balancer (even just a reverse proxy) and is designed such that you can restart every instance of the service without impacting any users of the full service.

    But there can certainly be cases where it would be convenient to push configuration changes without requiring a restart even if the down-side of a restart is only that performing it is inconvenient for your staff for some reason.

    I've worked on a lot of services that supported several different types of dynamic configuration. None of those were particularly difficult to implement, except for the most elaborate one which provided a telnet-like interface to each running service, which only made sense because these services were using a lot of threads. I'm not sure if that interface was ever used in Production even once. It had the potential to be a powerful tool, but such complex tools rarely find the confluence of a problem that can be solved by them along with a person working on the problem who sees how to solve the problem in that complex way "better" than more mundane techniques.

    How were all of the simple dynamic configuration facilities implemented? Well, first you need to consider the traps in dynamic configuration.

    If a configuration setting changes, then you risk having two parts of the system working with different values for that setting. Such can actually break parts of the service. So, if you are very careful, then you can write your code such that the value for a setting is fetched once at the start of the section of code where the value for that setting should remain constant. And then also be careful to not cache that setting too long such that a configuration change never fully takes effect (or can just take a very long time to fully take effect).

    Requiring your programmers to be very careful is usually a good way to introduce a lot of bugs.

    I find that many configuration changes just naturally only impact things when initialization is done. For example, if you have a configuration for the duration of the idle time-out when talking to some related service, then that time-out might be specified when you construct your connection to that service. So, your dynamic configuration system would have to somehow trigger the tear-down and re-establishment of such connections when a configuration change gets pushed (or trigger different code that can adjust the time-out of existing connections).

    That is why the dynamic configuration systems that I've worked with usually either only deal with a tiny subset of configuration settings (none of which have such traps associated with them) or achieve dynamic configuration by having the worker process get recreated when a configuration change needs to take effect.

    For the second case, the effect is only subtly different from the "restart the service to update the configuration model". Instead of the push process telling the instance of the service to restart, each worker notices (only at an appropriate point) that the configuration has been updated and restarts itself.

    And "notice a configuration change" was almost always just noting that stat indicates that some file has been updated.

    Even if you put your configuration in a git repo or in some database, there certainly are some advantages to pushing that configuration information to a particular server as a simple flat file that is trivial to parse (JSON being the best answer for that). Your database or git server needing maintenance should not lead to your service having to enter a maintenance window as well. Such maintenance should only impact your ability to automatically push changes to your configuration.

    Some of you may be concerned that this only prevents mis-matched configuration within a process. But, if you have something that two communicating processes must agree upon, you shouldn't be getting that value separately from configuration in each process. You should have one process telling the other process what value to use.

    - tye        

Re: Dynamic Config
by FreeBeerReekingMonk (Deacon) on Dec 07, 2016 at 08:13 UTC
    I can think of daemons that accept a kill USR1 or NOHUP signal to re-read their configuration... at the software's earliest convenient time. Others like Plackup have an -R to constantly monitor file changes, and reread the config file.

    The rest has been said by a fellow monk. The thing is: faulty config files also can make the program crash. So if pushed automatically, and re-read automatically... maybe an automatic rollback and human-signaling should be implemented.

Re: Dynamic Config
by mikkoi (Beadle) on Dec 07, 2016 at 11:46 UTC
    Thank you for the comments, especially for pointing out the two biggest problems:

    1. Webservers should be implemented with load balancing or similar which allows for different versions to be driven simultaneously. Java world has Tomcat which supports sessions that are "linked" to different versions of the same software.

    2. It makes the software more complicated, especially when running several threads. And therefore requires more developer discipline, and discipline must be maintained when developers and their management changes.

    That sums it up nicely. There could be a niche where this kind of dynamic configuration would be useful and worth the extra price - but not for the everyday biz web application. :-)

Re: Dynamic Config
by shmem (Chancellor) on Dec 10, 2016 at 15:09 UTC

    Some years ago I've written a drop-in replacement for Autoloader and uploaded it as AutoReloader. Something like that can be used for dynamic config changes.

    For example, you could tie a configuration hash to a class which runs a check subroutine at every FETCH, checking the timestamp of a config file against the recorded value at tie()-time; If the timestamp is newer, calculate the checksum of the file, reload it in case it differs from the recorded one, and remember the new timestamp (and checksum if reloaded).

    The penalty would the overhead of stat and a numeric comparison, in addition to the function call and the overhead of tie.

    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1177336]
Approved by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (4)
As of 2024-04-18 20:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found