Thanks for trying to help me, but I think what I was trying to do was impossible due to some of the limitations of the current implementation of phoenix pubsub. Or maybe I was just expecting too much from it …
I don’t really get what you are trying to achieve.
I wanted to get pids of all processes across all nodes subscribed to a topic. And some other things … I think.
In short, I had a mobile app with chat rooms and I needed to know which of the users are online are and which are not. To those who were not online, I wanted to send a push notification whenever a new message was posted in the chat room. To do that, I needed to keep a state of users who are members of a chat room and also the pids of active connections (users online).
It eventually was pretty trivial to implement with a genserver per chat room and linked cowboy websocket processes.
However, even with the pubsub abstraction, if I only had a single node, I could use a dynamic supervisor (thus a single node) which would spawn genservers for rooms on demand and terminate them when no more channel processes are linked. In each channel
join I’d just link that channel process to the corresponding genserver after (possibly) starting it. So the room genservers would’ve worked similarly to grains in erleans, but with grains I could go multi-node, but that would’ve been yet another overkill, in my opinion.
Are you trying to send messages to channels/sockets from another module?
It feels like Agent is a better fit if all you need is simple storing and retrieving.
No, agent would quickly become a bottleneck (or not, if you suggest an agent per chat room). The workaround with ets tables I’ve described in my second post could’ve worked though. But it didn’t seem clean to me since it was ultimately unnecessary (duplication of work).
start_link() instead of
start() to bind parent and child processes together.
What is a parent and what is a child in this case? I don’t think I mentioned anywhere that I was using
start() (since I wasn’t).