stuartc

Set initial state for process on start/restart

I have a GenServer that manages a varying set of interval timers.
By default, when you start it - the list is empty; and you add timers in
via the API.

I’d like to be able to fetch a list of timers from the database,
and add them to the process on startup (Supervisor).
In addition, if the process fails and is restarted by the supervisor
add the up to date list of timers from the database.

I imagine I need a parent process that itself is a supervisor,
in order to separate the IntervalServer from my main application.

I can’t quite figure out where/how I would hook such behaviour in,
i.e. call out to another process for data before restarting/starting a process.

6 comments

#supervisor #genserver

1 5129 6

2016-07-21 19:48:42 UTC

Marked As Solved

jwarlander

Strictly speaking, you can fetch your timer list in the init/1 function of your IntervalServer, eg:

defmodule IntervalServer do
  use GenServer
  # ...
  def init(:ok) do
    timers = MyApp.Repo.all(MyApp.Timer)
    {:ok, timers}
  end
  # ...
end

..and you’ll have the timers in your state. The drawback of this approach is that your database access is holding up the application startup sequence, and the application will utterly fail to start if the database isn’t available.

A different approach is to have init/1 return {:ok, [], 0}, which means it initializes with an empty array of timers, but a timeout of 0 milliseconds. When the timeout expires (immediately after startup), handle_info(:timeout, state) will be called, and you can load your state in that callback instead, without hindering the application during startup.. Eg:

defmodule IntervalServer do
  use GenServer
  # ...
  def init(:ok) do
    {:ok, [], 0}
  end

  def handle_info(:timeout, []) do
    timers = MyApp.Repo.all(MyApp.Timer)
    {:noreply, timers}
  end
  # ...
end

It depends on what your needs are. Doing it with timeouts, though, is the “friendliest” option – you can probably indicate in some other manner that the application isn’t ready yet, than having it fail to start at all. Perhaps some functionality is still useful, even without the database being (temporarily?) unavailable, etc.

NOTE: The IntervalServer can just be started in the top-level supervisor at this point, if you want to, eg. lib/my_app.ex in the start/2 function, as a worker.

Post #2

Also Liked

jwarlander

Should be fine too

As far as I can tell though, still best practice to do it from within init (which is executed in the context of the new GenServer process), eg:

def init(:ok) do
  Process.send_after(self(), :started, 0)
  {:ok, []}
end

def handle_info(:started, []) do
  # ...
end

Post #6

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

To be clear, both the start_link as well as init will block the start of the application. The supervisor will call start_link on the module which then synchronously waits for init to completely. So whether you’re putting the code in start_link or init it’ll still block the supervisor until it’s done.

Post #4