<div dir="ltr">Hey Max,<div><br></div><div>We also had a similar problem with our production. Our configuration (and states) were results of computations over a long period of time. </div><div>The system itself was managed by Mesos, so it was hard to use erlang hot updates, as it was suggested earlier (another topic, is </div><div>that hot updates are not trivial when you have multiple stateful processes).</div><div><br></div><div>Losing the state was quite painful for us, as it would require at least a couple of minutes to restore it. Which would result</div><div>in at least 100K failed requests from the customers. And because of our SLAs, it would have cost us quite a bit.</div><div><br></div><div>What worked for is Redis caching. It gave us reasonable performance + was external to our system (so it was easier to</div><div>re-boot nodes).</div><div><br></div><div>Best regards,</div><div>Oleg</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 20, 2020 at 11:23 PM Ameretat Reith <<a href="mailto:ameretat.reith@gmail.com">ameretat.reith@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I used to separate worker parameters to dynamic or static; static parameters<br>
would be set by supervisor but dynamic ones would be inducted from application<br>
env on worker initialization _or_ at runtime. So, each worker needing dynamic<br>
parameters, would have a `do_load_option` function invoking<br>
`application:get_env`  for each interesting dynamic parameter, and it would be<br>
called on worker initialization, e.g. in `init/1` for gen_servers then<br>
populate state. And like your approach, there was a `handle_call` to invoke<br>
`do_load_options` and reset state. This message would be sent on to workers<br>
found by `supervisor:which_children`.<br>
<br>
I had scripts (Juju hooks and then a homebuilt deployment system hook) that<br>
could set application env in sys.config on configuration changes. Then, that<br>
hook would call (rpcterms) a rpc on release to reload `sys.config`. This<br>
`reload_sys_config` calls `application_controller:change_application_data` to<br>
update envs and then procedures to call `do_load_options` on workers.<br>
</blockquote></div>