GenServer processing

You could do something like

def handle_call(msg, from, state) do
  spawn(fn -> 
    reply = do_stuff_with_message(msg)
    GenServer.reply(from, reply)
  end)
  {:noreply, state}
end

Here is an example.

HTTP Server.

defmodule HttpSrv do

  use Maru.Router
  plug(Plug.Logger)
  require Logger
  plug CORSPlug

  post do
    Logger.info("[Maru] Received a post request.")
  
    ## Start the processing of each request
    resp = Calculator.calc(5, 5)
    Maru.Response.json(conn, %{response: resp})
  end

end

The GenServer module.

defmodule Calculator do

  use GenServer
  require Logger

  ## Client API

  def start_link(_arg) do
    GenServer.start_link(__MODULE__, :ok, name: __MODULE__)
  end

  def calc(a, b) do
    GenServer.call(__MODULE__, {:calc, a, b}, :infinity)
  end

  ## Server Callbacks

  def init(:ok) do
    {:ok, %{}}
  end

  def handle_call({:calc, a, b}, _from, state) do
    result = a + b
    {:reply, result, state}
  end

end

You don’t even have to reply in another process. The trick is that handle_call doesn’t have to reply immediately. So the state of the call can be stored in the GenServer state and once the reply is ready GenServer.reply/2 can be used to complete the call. Just remember that on the client side there is a timeout.

If they do not need to alter the state of the GenServer, then @voughtdq’s solution works fine (though they will still be serialized; but the time they block each other will be minimal, just the time require to spawn the process and return from handle_call).

The caveat in @voughtdq’s approach is that the requests can not change the state of the GenServer. So as long as the GenServer’s state is immutable with respect to the requests, that will work quite fine until you really start hammering it with requests (.. and then, the handle_call is unlikely to be the bottleneck).

If requests do need to change the GenServer’s state, then you need a different solution, though it will also involve spawning multiple processes so they can service requests in parallel.

Additionally, that approach offers no mechanism for back-pressure or rate-limiting on its own, though it could be added …

I have already tried this but it is waiting before entering the handle_call. It is waiting where I call the Genserver.call function.

Edit: ignore. calc is part of the client API, not the server processing.

Wait, do you mean that the HTTP server is blocking?

Exactly. It is blocked and doesn’t accept more calls until the previous one has finished.

No, not the HTTP, the GenServer as @peerreynders already said.

Building Non Blocking Erlang apps

Also: Why does this simple GenServer timeout? - #4 by peerreynders

Your could for example launch the calculation call via Task.async/1 which gives you a %Task{owner: term(), pid: term(), ref: term()}. Store that together with the caller details in the GenServer state.

When the task is done, you’ll get a {ref,result} via handle_info and you can complete the call with GenServer.reply/2.

For a cleaner result, also take care of the details like Task.await does, i.e. demonitor and process :DOWN messages