[erlang-questions] Use of application environment
Wed Dec 3 05:29:41 CET 2008
Thanks for your reply.
On Tue, Dec 2, 2008 at 11:08 PM, Serge Aleynikov <> wrote:
> Note that there's already a config_change callback in the OTP application
> behavior that can be used as a notification mechanism.
> This post illustrates a way to reload the application's configuration and
> trigger the config_change callback so that the application can perform
> dynamic reconfiguration without restarting:
That's very interesting. I had seen config_change before while looking for
something else in the application module, but I seem to develop a kind of
"tunnel vision" that focuses on what I need to know right NOW and skips over
other details, so I hadn't paid it much attention and frankly forgot about
it until now. There's SO much to remember in Erlang (and any major
environment like it). Something that would have put me off track is the
documentation that states "This function is called by an application after a
code replacement, if there are any changes to the configuration parameters."
I would have thought a code replacement was necessary, so your insight is
I assume, reading the code you linked to, that one still needs to include in
the config_change callback something to propagate the changes to the various
workers and supervisors. Do you think that the subscribe/notify mechanism I
described is workable?
> This is a simplistic approach that doesn't involve configuration
> validation. Actually this was a part of a configuration management
> framework that we developed at my former employer that included a
> configuration server that maintained the versioned configuration repository
> that also performed syntax verification based on the application's metadata
> deployed with each app that included all needed parameters for each
> environment type (e.g. prod/dev/qa/etc), parameter types, defaults, update
> actions (such as reload environment, restart application, restart node,
> etc.), parameter documentation. The server would perform configuration
> validation based on this metadata and reject unconformable input. Each node
> would run a configuration client that upon startup would query the
> configuration server and rebuild the local configuration file if there were
> any parameter changes. It would then use that configuration file in
> starting a release.
That's pretty sophisticated and along the lines of what I had envisioned.
It's a pity I don't have the time to write something like that. Your former
employer was evidently unlucky to lose you :)
Do you by any chance remember if the metadata was able to describe complex
terms involving nested lists and tuples? Also, do you know of something like
type_of(Term) (besides is_integer/1 and the others) available somewhere in
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions