zzebra

zzebra

Hi all,
I’m creating a GRPC Client using grpc that deals only with unary RPCs.
I want to use the same gRPC channel as much as possible and not open new ones for each request.
So I decided to create a GenServer that is responsible for

  • creating the channel on app start
  • keeping the channel open and try to reopen if it was lost for some reason

My goal was to keep my app running when the gRPC Server is down and be able to re-create the connection once the Server is back again.

Genserver code

defmodule App.GRPCChannel do
  use GenServer
  require Logger

  alias App.Settings

  # client
  def start_link(_) do
    GenServer.start_link(__MODULE__, :ok, name: __MODULE__)
  end

  def channel() do
    case GenServer.call(__MODULE__, :channel) do
      %GRPC.Channel{} = channel -> {:ok, channel}
      _ -> {:error, :no_connection}
    end
  end

  # server
  @impl true
  def init(_) do
    initialize_channel()
  end

  @impl true
  def handle_info({:gun_down, _, _, _, _}, _state) do
    Logger.debug("GRPC Server not connected.")

    {:noreply, :no_connection}
  end

  @impl true
  def handle_info({:gun_up, _, _, _, _}, state) do
    Logger.debug("GRPC Server connected")

    {:noreply, state}
  end

  @impl true
  def handle_info({:gun_up, pid, _}, :no_connection) do
    Process.exit(pid, :kill)

    Logger.debug("GRPC Client killed zombie Gun process, pid: #{inspect(pid)}")

    {:noreply, :no_connection}
  end

  @impl true
  def handle_info({:gun_up, pid, _}, state) do
    if pid != state.adapter_payload.conn_pid do
      Process.exit(pid, :kill)
      Logger.debug("GRPC Client killed zombie Gun process, pid: #{inspect(pid)}")
    end

    {:noreply, state}
  end

  @impl true
  def handle_call(:channel, _from, channel) do
    case channel do
      %GRPC.Channel{} = channel -> {:reply, channel, channel}
      :no_connection -> restart_channel()
    end
  end

  defp restart_channel() do
    case initialize_channel() do
      {:ok, :no_connection} -> {:noreply, :no_connection}
      {:ok, channel} -> {:reply, channel, channel}
    end
  end

  defp initialize_channel() do
    address = Settings.iam_service_url()
    opts = Settings.iam_service_connection_opts()

    Logger.debug("GRPC Client connecting to gateway at #{address}")

    case GRPC.Stub.connect(address, opts) do
      {:error, error} ->
        Logger.critical("GRPC Client could not connect to GRPC Server. Message: #{error}")
        {:ok, :no_connection}

      {:ok, channel} ->
        Logger.debug("GRPC Client connected to the gateway at #{address}, using channel: #{inspect(channel)}")
        {:ok, channel}
    end
  end
end

The main ideas are

  • to only try to re-create the connection once channel() is called and it is a :no_connection.
  • use the default gun adapter and its messages to get info about the inner http server state - and based on that return have the channel itself or :no_connection as Genserver state.

When a gRPC request is fired it starts with fetching the channel every time, like this:

  def authenticate(resource_id, access_token) do
    with {:ok, %GRPC.Channel{} = channel} <- get_grpc_channel(),
         {:ok, %AuthenticateRequest{} = request} <- build_authenticate_request(resource_id, access_token),
         {:ok, %AuthenticateResponse{} = response} <- Stub.authenticate(channel, request) do
      {:ok, %{success: response.success, user_id: response.user_id}}
    else
      {:error, :iam_service} -> {:error, :iam_service}
      {:error, %GRPC.RPCError{} = _error} -> {:error, :unauthenticated}
    end
  end

  defp get_grpc_channel() do
    try do
      GRPCChannel.channel()
    catch
      :exit, _ -> {:error, :iam_service}
    end
  end

I need to catch the Genserver’s error here since it may exit when it couldn’t create a channel.

By trial and error (switching on and off the GRPC server) I noticed that the GRPC server might bring down my entire app due to the Supervisor retry logic, so I try to avoid it.
I also noticed that after restarting the GRPC server, the old gun process might re-connect and come back while the new one is also alive, that’s why I’m killing it, to keep only 1 alive.

I’m wondering how bad ideas are these…

All feedbacks are welcomed.

Showing Posts 1 to 2

D4no0

D4no0

You might want to create a backoff strategy for your supervisor (or you can add that logic in your genserver), here is a small example of how this can be achieved: https://stackoverflow.com/a/47996476/8103819

zzebra

zzebra OP

Thanks! I was thinking about it, but than I was thinking I only need the channel when a request wants to use it. In that case channel() will either return an existing channel or try to create one. With a backoff I’ll do the retry earlier in an automated manner, but I’m not sure what would be the benefit of doing that.

— All posts loaded —

Where Next? Top

Trending in Questions Top

katta
I having some trouble figuring out if I have set myself too strict of standards for my production server. Currently I can handle 75% of r...
New
brecabral
Documentation While reading the Scoped Routes section, I noticed that the documentation currently refers to a problem without explainin...
New
achenet
Hello, I’m trying to build a basic Phoenix web-app, and I’d like to use Tailwind. However, when I launch mix phx.server, I get an error...
New
kpanic
Hi everyone, I am toying with the idea of building a “match maker” for giving personal help to people that wants to start coding. I sta...
New
asweet-confluent
I recently noticed that Elixir’s Logger defaults its primary log level to :debug when no :logger, :level application configuration is pre...
New
Cxx-mlr
I’m working on a small exercise involving update_in/3, and I came up with this solution: data = %{ name: "Periodic Table", category:...
New
ChrisAmelia
I’ve got trouble wrapping my head around the order in which functions are called in this snippet (from Phoenix’s authentication): toke...
New

Other Trending Topics Top

GenericJam
Edit: 2026 May 15 - This post is archived. Mob is alive!! Main docs: mob v0.7.11 — Documentation A bit of explanation for the slightly c...
New
JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
budgie
A little off-topic, but I feel like people here have a good head on their shoulders. I used to be quite good at making software. Was luc...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews