Re: Supervisor and configuration update — how to do it?

[Tristan Sloughter]

You can update the childspecs with either an appup or manually using the steps an appup does of suspending the process and replacing its state with `sys` calls.

Can't use that for the top level supervisor but if that crashes you go through the application start process anyway where you can pick up the new config state to pass along?

On Tue, May 19, 2020, at 23:36, Max Lapshin wrote:
> Hi.
> 
> Our flussonic has big amount of code related to smooth configuration
> update. Almost all configuration parameters can be changed on fly: it
> is very important, because we handle big amounts of video traffic.  It
> is very bad to leave 20 000 people without video if you want to
> reconfigure single channel.
> 
> 
> We have to fight with supervisor concepts: we do not accept
> configuration in start_link/init, because it may change later.
> 
> Usually code is looking so:
> 
> 
> init([Options]) ->
>   {ok, update_options(Options, #state{})}.
> 
> handle_info({update_options, Options}, #state{} = State) ->
>   {noreply, update_options(Options, State)};
> 
> 
> 
> Such approach doesn't work well with supervisor: if process is
> restarted, it will be restarted with old Options.
> 
> My question is: is such approach antipattern for OTP?
> Maybe someone else has already met with it and has some ideas about
> it, like modifying supervisor.erl to change MFA?
>