Automatically starting applications in the correct order

The problem with this approach is that the application is not included in the application list, even though it’s required at runtime. This means you can’t build a proper OTP release with distillery (I’m presuming you’re not doing it now, but might want to do in the future). Any other tool which relies on the application list will also not work properly.

Instead of using runtime: false, you could instead add the vmstats application to the included_applications list:

# mix exs
# ...
def application do
  [
    included_applications: [:vmstats],
    # ...
  ]
end

And then somewhere in the supervision tree include %{id: :vmstats, start: {:vmstats, :start, [:normal, []]}} as a child. This will work properly with distillery, since application will be included in the release, but it won’t be started when the release is booted. Instead, the app is started in your own supervision tree.

Alternatively you could use vmstats normally (i.e. drop included_applications and runtime: false). In your app startup callback you could invoke something like Application.put_env(your_app, :statix_connected?, true) immediately after invoking Statix.connect, and then in your sink callback function push the data only if Application.get_env(your_app, :statix_connected?) == true.

6 Likes