[erlang-questions] Use of application environment

Mazen Harake mazen.harake@REDACTED
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 :)

/Mazen

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
> difficult.
>
> 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
> settings.
>
> 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.
>
> Adam.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>   




More information about the erlang-questions mailing list