shijith.k
Genserver timeout error on :no_reply response
I have GenServer setup in a module. One of the handle_call/3 returns {:no_reply, state}. Every time after executing the call a timeout error raises. Can someone tell me what I am doing wrong here? This is the first time I am trying GenServer.
My code looks like this:
defmodule TestApp.Message do
alias TestApp.Message
use GenServer
import Logger
def init(args) do
{:ok, args}
end
def start_link(_) do
GenServer.start_link(__MODULE__, [], name: __MODULE__)
end
def handle_call({%{"message" => message}, state}, _sender, _current_state) do
info("message")
{:noreply, state}
end
end
This is the error message:
{:timeout, {GenServer, :call, [MyApp.Message, {%{"message" => message}, %{id: 1, sender: "user1}}, 5000]}}
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Error tracking, logs, APM, uptime and cron monitoring in one dev-friendly platform. Find and fix problems before your users notice.
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
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #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.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
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!"
First 5 of 5 Posts
rvirding
The
{:noreply, state}return value tells the behaviour not to send a reply to theGenServer.call. As it has built-in timeout of 5 seconds (which can be changed) then it will timeout when a reply does not arrive within that time. You need to explicitly send back a reply by returning{:reply, reply, state}.shijith.k
I am planning to set up a connection with an iOT device, which does not expect a reply there. In such cases what can I do?
kokolegorille
You need to use handle_cast in this case…
rvirding
Yes, one way is to use GenServer.cast/handle_cast. One problem with that is that is gives no guarantees of the destination being there or the message arriving as it literally uses :erlang.send internally. For more safety you could use GenServer.call/handle_call and return the reply :ok. NB that this is doing a synchronous call with all that it costs but you will at least be certain the message has arrived and has been processed.
It’s all a matter of deciding what you need/want and are willing to pay for it. TANSTAAFL
lucaong
In other words, when you use
handle_call, your caller (the process that callsGenServer.call) expects a reply. One can return{:noreply, state}fromhandle_call, but only if the reply is computed asynchronously and then sent later withGenServer.reply.As @rvirding and @kokolegorille wrote, you have two options:
Return a simple reply like
{:reply, :ok, state}. This ensures thatGenServer.callwill return:okonly after the operation that you perform in theGenServercompletes. This is, generally, the best way, as it ensures that whatever you wanted to execute actually does execute.Alternatively, if you really don’t care about the answer, and also you don’t need to guarantee that the
GenServeractually performed the operation, you can useGenServer.castandhandle_cast.