[erlang-questions] reload application configuration
Tue Nov 12 22:09:02 CET 2013
We use the OTP application environment for configuration data almost exclusively in the systems we build at Heroku. Logplex ( https://github.com/heroku/logplex ) is an example of one of these. We do a few things to make it more usable for us.
* application:get_env(my_app, key). is really fast - it's just an ETS read, so do it pretty much everywhere except in a tight loop. -- https://github.com/heroku/logplex/blob/master/src/logplex_message.erl#L73
* This means your app automatically pick up and use changes in this configuration.
* If you have a tcp listener, don't pass its Port configuration via supervisor start arguments, have the init routine for the listener read application:get_env -- https://github.com/heroku/logplex/blob/master/src/tcp_acceptor.erl#L57
* This allows you to update the app_env config and then apply it by doing a terminate_child and restart_child on the listener process from the supervisor.
* If you read configuration from the unix environment into your OTP app environment, maybe use a library to make that less painful. https://github.com/heroku/logplex/blob/master/src/logplex_app.erl#L84 and https://github.com/heroku/stillir
When we used to cache configuration all over the place in gen_server state and supervisor child specs, updating the configuration was really difficult. Now that we avoid that, we find the OTP app env really good for configuration data and like the centralised storage in ETS, the ability to inspect it with get_all_env, quick updates and all the support for -app env_key env_value, -config <file>.config and so on.
On 2013-11-12, at 02:17 , Ignas Vyšniauskas <> wrote:
> I've too struggled with this problem quite a few times.
> One thing I never got to try out: What about pushing relups with only
> configuration data changed? Then you get versioning for free, you can
> also specify how each application should deal with the new configuration
> data (just update it / stop / restart gen_servers, etc).
> You get all the release goodies and would basically just need to write
> some scripts to generate "light" relups.
> Your application's would also need to have a proper `config_changed/2`
> callback, but this IMHO is much nicer than rolling your own thing.
> If you are doing releases and relups already (and you should!) then this
> seems like a decent path to follow.
> erlang-questions mailing list
More information about the erlang-questions