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

[Loïc Hoguin]

In Ranch 2.0 the options are put in an ets table, and then fetched from 
those tables in the supervisor init functions. The same could be done 
using persistent_term.

On 20/05/2020 07: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?
> 

-- 
Loïc Hoguin
https://ninenines.eu