xoron
When ever a user connect to our phoenix channel like user join a channel when he login and leave channel when logout.So whenever it join channel we create Postgress notification process and listen to triggers
{:ok, pid} = Postgrex.Notifications.start_link(repo_config)
{:ok, ref} = Postgrex.Notifications.listen(pid, "#{@channel}#{Enum.at(args, 0)}")
When user logout or leave channel due to some other reason like close browser we unlisten and stop the process.
Postgrex.Notifications.unlisten(state.pid, state.ref)
:gen_server.stop(state.pid)
Is This good Approach.
Other Approaches in my mind are.
- Create single Listener Genserver then broadcast to respective user.(Reason may create
bottleneck ) - Create pool of Genserver and main listener Genserver just receive from Postgres and send to other Genserver from pool which then do some processing and broadcast to user channel.(Processing involve some data manipulation not any heavy task just add and check some field in user struct)
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
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.
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
kwando
I think every postgres listener will have its own connection to the database which might be problematic if you expect a lot of users.
I would start with a single listener, keep an eye in it and then reach for something more involved if it proves to be a bottleneck.
xoron
Are they not using connection pool ? So if they using connection pool then it still problematic ?
benwilson512
The notifications process is a dedicated connection, it is NOT using the pool. It fundamentally can’t, it needs to reserve the connection to receive messages. It can’t simultaneously do that and be available for queries in the pool.
You’ll want to run one of these per node and then do an Elixir level fan out of those messages to other processes that care about them.