[erlang-questions] reload application configuration

[Benoit Chesneau]

On Tue, Nov 12, 2013 at 10:09 PM, Geoff Cant <nem@REDACTED> wrote:

> 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.
>
> Cheers,
> --
> Geoff Cant
>


Sorry for the late answer. Thanks for the useful information and links,
stillir was the bit I was missing. With that your method and the one
proposed by Max Lapshin I think I will be able to do something. It will
reduce a little the number of conf levels I need.

The last thing I need to figure is to find a way to mix that with
cuttlefish (https://github.com/basho/cuttlefish) so the end user will have
a human friendly configuration file (or sort of).

- benoit



> On 2013-11-12, at 02:17 , Ignas Vyšniauskas <baliulia@REDACTED> wrote:
>
> > Hi,
> >
> > 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.
> >
> > --
> > Ignas
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131119/0cea7737/attachment.htm>