Re-think supervision strategy
keathley opened this issue · comments
Because the Store is responsible for setting up the watches as well as managing configuration and the ets table, its possible that the watches crash and are never properly restarted. We need to re-think the supervision tree and methodology that we're using to solve this issue.
Hey @keathley any progress on that ? I am having multiple project where i would like to standardize on Vapor for some runtime config. This is probably the most urgent i suppose.
I could try to think through some supervision tree and architecture structure for this and have a go at it ? If it would be helpful
I think the most reasonable change for this would be to move the internal ets table that houses all of the actual config state into the top supervisor. We can serialize all changes to that ets table through the existing store process but it doesn't need to own it so that if it crashes the ets table won't be lost.
make sense. I am not a fan of state in the supervisor but probably the most reasonable for now.
What about starting a process dedicated to the ETS table as a first child instead ? We can do a rest_for_all on it with the other... Not much cleaner i suppose.
Fixed in #51