rafaeliga
Liveview + PubSub messages delay?
Hello there,
I have a Liveview that subscribes to a Pubsub topic and starts a Genserver when I click in a button.
The Genserver sends a message back to the Liveview using the Pubsub, those messages seems to only be processed after the map ends:
If I increase the data, from 1000 to 10000000, I see that some of messages being received before:
Is there a way to receive those message before?
I have created a repository to reproduce: GitHub - rafaeliga/liveview_pubsub_update: Sample project to test Liveview + Pubsub · GitHub.
Marked As Solved
benwilson512
Yes, but start is blocking handle_event, which blocks handle_info. start does not return until init returns. This means that handle_event doesn’t return until init returns, which means that the live view is unable to do any handle_info calls until init has published all of the messages.
EDIT: To elaborate further: A live view is a genserver, and a genserver is a single process. A single process can only run code linearly, and that means that a given callback from a genserver can only run one at a time. As long as handle_event is blocked, the genserver loop of the whole liveview process is blocked, which prevents any handle_info clause from running. If you change your broadcaster to do:
def init(_params) do
send(self(), :broadcast)
{:ok, nil}
end
def handle_info(:broadcast, state) do
Enum.map(1..1000000, fn datum ->
Logger.info("process: #{datum}")
Phoenix.PubSub.broadcast(LiveviewPubsubUpdate.PubSub, "import_live", {:message, datum, Timex.now()})
end)
Logger.info("Enum map finished")
{:noreply, state}
end
You should see more of what you expect.
Also Liked
rafaeliga
Thank you @benwilson512 !
The code below worked:
def init(_params) do
send(self(), :broadcast)
{:ok, nil}
end
def handle_info(:broadcast, state) do
Then looking at the Genserver documentation, handle_continue did the job too:
@impl true
def init(_params) do
{:ok, nil, {:continue, "continue"}}
end
@impl true
def handle_continue("continue", state) do
benwilson512
You call start in handle_event. Start is not in another process, it’s in the liveview process. init is in another process, but start waits on init to return before it returns, that’s part of the standard genserver contract see:
iex(4)> defmodule Foo do
...(4)> use GenServer
...(4)>
...(4)> def start() do
...(4)> GenServer.start(__MODULE__, nil)
...(4)> end
...(4)>
...(4)>
...(4)> def init(_) do
...(4)> Process.sleep(1000)
...(4)> {:ok, nil}
...(4)> end
...(4)> end
iex(7)> :timer.tc(fn -> Foo.start() end)
{1000836, {:ok, #PID<0.145.0>}}
EDIT: Further reading
https://github.com/erlang/otp/blob/master/lib/stdlib/src/gen_server.erl#L74-L91
thiagomajesk
Oh, I see, that makes total sense! Thanks for the well-rounded explanation @benwilson512. I completely forgot that the GenServer process everything linearly like you mentioned (because it’s basically just a loop waiting for its time to process something). This definitely is what’s going on here.
Popular in Questions
Other popular topics
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










