It is also important to guarantee the :sasl application is started before the :logger application. Otherwise you will get duplicate reports.
Your mix.exs should look like this:
extra_applications: [:sasl, :logger]
In such cases, the programmer must ensure that applications are started in the correct order.
Perhaps it would be possible implement an improvement, such that applications are automatically started in the correct order? To make this work, I suppose each application would need to declare its own “startup dependencies” and/or “startup importance level.”
This would effectively move the responsibility of starting applications in the correct order from the programmer who uses the application, to the programmer who develops said application.
I don’t know whether this is doable; it’s just a thought that struck me whilst reading.
As far as I can tell, the same challenge exists in Erlang as well:
Which applications to include is defined by the included_applications key in the .app file […]
When starting a primary application with included applications, the primary application is started the normal way, that is:
The application controller creates an application master for the application.
The application master calls Module:start(normal, StartArgs) to start the top supervisor.
Then, for the primary application and each included application in top-down, left-to-right order, the application master calls Module:start_phase(Phase, Type, PhaseArgs) for each phase defined for the primary application, in that order.
That is, the programmer is responsible for starting the applications in the correct order, by placing them in the correct order in the .app-file (under the included_applications key-key).
Perhaps this could be automated somehow by Elixir?
AFAIK the sasl is no longer an issue in OTP 21, since the logs are now produced by the erlang’s new :logger that is always started. sasl is now only what it was always supposed to be - just tooling for releases.
Are you aware of any other cases where the order in which the applications are included is significant, or was this just an odd exception case when using sasl in combination with logger?
@IRLeif I’m running into a similar problem trying to send vmstats information to statsd via statix. I need to ensure that statix has connected to the statsd server before the vmstats application has started. The solution I came up with was to set the vmstats dependency to runtime: false and manually start it in my main application.
defp deps do
[
# ...
{:vmstats, "~> 2.3.0", runtime: false}
]
end
def start(_type, _args) do
:ok = Strategies.Statix.connect()
Application.start(:vmstats)
Supervisor.start_link([], strategy: :one_for_one, name: MyApp.Supervisor)
end
It would be fantastic if there was some way to specify the order in mix.exs without clobbering all applications by adding the applications key to def applications
I thought I had misunderstood something and made a fool of myself by posting this thread, so I’m glad to hear that somebody else might be having a related issue to vindicate me
I’m too much of a newbie to be able to provide advice for your specific situation, @rupurt, but I’m sure one of our forum friends of greater clout will swing by and knock it out the the park.
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.
@sasajuric thanks for the detailed insight. You’re correct, I’m not deploying my app yet but did plan on using distillery for an OTP release so this has saved me a wall of head bashing in the future
Both approaches sound interesting and I can actually see me needing better error handling in the sink for when the statsd server is down etc… so I’ll probably go with that approach.
