Can a Supervisor and a child Genserver subscribe to the same topic?

Questions / Help
, ,
1

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:

  1. A DynamicSupervisor subscribes to a pubsub topic, :inbound_message_received.
  2. 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?

2

Yes it’s possible

But what does the supervisor do, that cannot be solved by a registry?

3

The idea for the supervisor was that it would be responsible for starting a conversation’s GenServer in case the conversation was happening for the first time, or if that conversation’s GenServer had been killed/crashed/whatever.

4

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.

4 Likes
5

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…

1 Like
6

Ah, that makes sense, and that’s clearly the way to do it!

The original idea was to keep a very strict separation of concerns between the phoenix/webserver side and the “process messages” side. So the webserver would just broadcast “hey, I got a message!” and then it would be the part of the software that handles conversations that would figure out what to do with the message.

Would that then necessitate having a pool of supervisors so that they don’t become bottlenecks?

7

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

1 Like