sergey-chechaev
Heavy work when starting DinamicSupervisor
Hello, I don’t find any common approach to start heavy work or children’s processes after DynamicSupervisor started. When we restart application or DynamicSupervisor is crash, we need to start DynamicSupervisor children’s processes or do heavy work as the handle_continue function when we use GenServer. In our project, we use start_link for this:
defmodule SomeDynamicSupervisor do
use DynamicSupervisor
alias SomeGenServer
def start_link(_) do
with link <- DynamicSupervisor.start_link(__MODULE__, %{}, name: __MODULE__) do
Task.async(fn -> start_child_processors() end)
link
end
end
def init(_) do
DynamicSupervisor.init(strategy: :one_for_one, max_restarts: 10)
end
def start_child_processors do
SomeLogic.list_of_ids()
|> Enum.each(&init_processor/1)
end
def init_processor(some_id) do
opts = [name: NameGenerator.processor_registry_name(some_id)]
DynamicSupervisor.start_child(__MODULE__, %{
id: "#{SomeGenServer}_#{some_id}",
start: {SomeGenServer, :start_link, [opts]}
})
end
end
What pitfalls does this approach have? Perhaps there is a better way. Can anyone share it with me?
Trending in Discussions
Other Trending Topics
Chat & Discussions>Discussions
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #performance
- #security
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First 6 of 6 Posts!
LostKobrakai
Why would you use a DynamicSupervisor is instead of a static/normal one here? It feels like a normal supervisor would suite your need better.
sergey-chechaev
I need to create processes dynamically. But it’s not matter. My question what the best practice to start a bunch of children processes when we start
DynamicSupervisor.kwando
I would nest the DynamicSupervisor under another Supervisor with the strategy
:rest_for_oneand also add a setupTaskafter the DynamicSupervisor in that supervisor.If your DynamicSupervisor crash it will be detected by the
Supervisor.sergey-chechaev
Great, we also considered this option. But we wanted to make it a little easier for understanding and putted the warm-up function to
DynamicSupervisor. Also,DynamicSupervisorstarted by application.ex so supervisor up it if it fails andDynamicSupervisorrun warm-up function itself. One best thing thatstart_linkguaranteed thatDynamicSupervisoris up.LostKobrakai
Ordering for supervisor children is guaranteed. If the process to start your task is after the
DynamicSupervisorchild then it will only run once theDynamicSupervisoris indeed successfully started. You’re not making this simpler, by trying to mush together different responsibilities.sergey-chechaev
Yes, maybe you are right that we need to share responsibility like suggest @kwando: