[erlang-questions] Dependencies, included applications and supervision

[Jay Nelson]

On Jun 25, 2014, at 2:28 PM, Loïc Hoguin <essen@REDACTED> wrote:

> I'm not sure how that's related. pg2 isn't an application. It's not written this way for handling restarts, because as you can see it's marked as permanent, and if kernel_safe_sup dies the Erlang node is killed anyway. The VM doesn't start pg2 by default, which is probably why this function is there.
> 
> It's ugly, but it's completely unrelated to the topic at hand.

There’s no difference between an application that is not started by default on 
start up (but is used at some later time), and one that crashes after being
started and is needed later and must be restarted.

My point on restricting use was made because library and application developers
should be aware that even though they themselves may not use or like included_applications,
it is incumbent on them to provide a complete solution and that they be aware of the
existence of included_applications and the guidelines that must be followed to enable
their use. Most cases when included_applications were not allowed by default
(and there have been several including an OTP application which I patched)
were because of initialization prior to the start of the root supervisor, or the lack
of an exported function to call the root supervisor (which most often happens
when people try to save files by putting application and supervisor in the same module).


The drawback to using included_applications comes with start_phases. When there
is a sequence of dependencies that must be started in a particular order the built in
method is to code start_phases in your application module and invoke them in order
from the .app.src. There is a minor problem in that the including application must
be aware of all start_phases of all included applications and must have a superset
of all start_phases specified.

The bigger obstacle that makes start_phases problematic comes in that they are
not invoked from the supervisors, but from the startup sequence, so they are never
invoked during a restart. With complex startup dependencies among multiple
applications, you may need to quickly start a static supervisor hierarchy (possibly
without children) and then programmatically trigger the instantiation of children.
This approach can be run at any time, not just at startup, so you can programmatically
enable start_phase-like functionality during restarts with your own code. This is
probably when a VM node restart is more likely to be the easy path, but is also the
case when restarting a node is likely to take a significant amount of time.

I am not aware of anyone else in the community who as advocated included_applications.
I have never come across an OSS library that uses included_applications other than my
own, although I do know Ericsson built and uses these features for a reason. I think this
aspect of OTP is probably the weakest aspect, and I would welcome alternatives that
more closely resemble a soup of peer services with less rigidity than a supervisor
hierarchy and which allow and enforce restart logic and start_phases in a sane way,
yet still allow awareness of whether dependencies are currently running or not.

jay