elbasti
Can a Supervisor and a child Genserver subscribe to the same topic?
Hi folks, looking for some very basic beginner-level advice on architecture OTP applications.
I’m building a hobby-project application that receives external messages and then replies to them, and the replies depend on the conversation our application has had with that particular recipient.
The messages are received by a Phoenix application, and I’d like for a separate OTP application to be responsible for determining if/how to reply. The architecture I have in mind is:
- A DynamicSupervisor subscribes to a pubsub topic,
:inbound_message_received. - Upon receipt of the message, the supervisor does one of two things:
a. Start a child GenServer that will then load the conversation we’ve had with that recipient as state, and then determine if/how to reply.
b. Find an existing GenServer corresponding to that conversation, and then let it know a new message has arrived.
A few constraints:
- Conversations are “bursty.” Sometimes there will be lots of back and forth, in which case it makes sense to keep the child servers alive, but they also go dormant, in which case it makes sense to kill them after a while until a new message is received.
- The work done by the child servers can take a long time.
So the very first question I have is:
It seems kind of silly to have the supervisor listen to all new messages only to delegate them to the child servers that may or may not already exist. Naively, I think the children should subscribe to that topic as well–that way they can respond immediately if they already exist.
¿How would you handle that? ¿Can both a supervisor and a child of the supervisor subscribe to the same PubSub topic?
Marked As Solved
jswanner
I wouldn’t use a supervisor to listen to all messages and route them accordingly, as that supervisor will become a bottleneck.
Instead, I would write a function that was called from the client process (your Phoenix controller/liveview process) that was responsible for looking up the pid (or starting a new process) and calling it. That look up code would use something like GenServer.whereis with a :via tuple. With that setup, I wouldn’t need PubSub for the handling of incoming messages, but I would likely use PubSub for broadcasting out from the GenServer that a message had been received and processed.
Also Liked
kokolegorille
Yes, something like this…
def get_worker(name) do
case WorkerSup.start_worker(name) do
{:ok, worker} -> worker
{:error, {:already_started, worker}} -> worker
_response -> nil
end
end
This is what I meant to lookup via a Registry…
jswanner
There’s a difference between separation of business logic concerns and separation of processes. Modules are for organizing functions, processes are for runtime concerns.
No, I don’t think that would be necessary. There’s already multiple client processes (controller/LiveView processes), by doing the process lookup from them the supervisor won’t be a bottleneck (the registry might, but I wouldn’t worry about that until you can prove it’s a problem). I think you want to focus more on how the code is organized into modules more than anything
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
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
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance
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.
Real-time error tracking, performance insights, and observability for devs.
Develop your skills with books, videos, and courses.
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!"