[erlang-questions] Use of application environment
Tue Dec 2 12:47:11 CET 2008
Personally from experience I always end up thinking of design that
allows the system to be gradually upgraded. (Some of our projects do
just this). Actually this is a really good thing because you can treat
the nodes you are upgrading as being "down".
E.g. if you have a cluster of several frontend and backend nodes etc...
then you should be able to split it up, upgrading a few of each... then
test your upgrade went fine... transfer the traffic... then upgrade the
other part and enable traffic on all again.
Has worked nice so far.
As for the update of configuration, It is probably Always best for heavy
long lived processes to be able to decide when a good time to update the
configuration is specially if the process has a state which has been
based on configuration. You don't want to mix configuration :)
Adam Kelly wrote:
> 2008/12/2 Edwin Fine <erlang-questions_efine@REDACTED>:
>> I was holding off from replying and hoping to receive more opinions and
>> thank everyone at once, but I guess no more are forthcoming. Many thanks to
>> you and wde for your input.
> I took the decision early in my Erlang learning that individual
> servers shouldn't know whether or not they are part of a supervision
> tree or an application in order to avoid cyclic dependencies.
> Therefore, I call application:get_all_env/1 from my application
> module, pass the resulting list to the top level supervisor which
> passes the relevant configuration information to each part as needed.
> The upside is that this really help with testing as I can easily test
> individual gen_servers with different configuration settings. On the
> other hand, it makes changes to configuration settings at runtime very
> For the one application that needs to be reconfigured regularly, I've
> implemented a reconfigure command which rereads the configuration file
> and sends messages to the relevant workers informing them of the new
> I'm not sure if this is the best solution in general, particularly
> when it comes to core parts of the system that can't really be run in
> isolation for testing anyway and it always creates the risk of
> accidentally running with old cached configuration info.
> As regards upgrades, I tend to assume significant upgrades will cause
> crashes, and rely on the self-healing property to do the right thing.
> The system is designed to crash without interruption to service so I
> let it do just that.
> I'm also very interested as to what approach others take to this issue.
> erlang-questions mailing list
More information about the erlang-questions