[erlang-questions] Dependencies, included applications and supervision

Fred Hebert mononcqc@REDACTED
Thu Jun 26 00:52:43 CEST 2014

On 06/25, Jay Nelson wrote:
> Not every application can be separate. We have an application called ‘presence_server’
> which is embedded in every node. When the server comes up, and is finished with its
> full initialization, it announces “service available” so that other nodes can contact it. If
> the presence_server is run as a sibling application, it can go down and cause services
> to be unavailable until it is restarted.

What happens if the server fails repeatedly then? Does it crash the
node, but only after another cycle of crashing everything?

If your app is designed as:

        [AppSup]                [PresenceSup]
         /    \                        |
     [SubSup] [SomeWorker]         [Server]
     /  |  \

Let's say I allow AppSup to crash 10 times a minute, and I allow
PresenceSup to crash 3 times per hour. If I make the latter permanent,
after 3 failures in an hour my node crashes.

In the included_application scenario I can go:

         /    \                        |
     [SubSup] [SomeWorker]         [Server]
     /  |  \

In which case my presence sup now needs to crash 3 times and hour, and
then 10 times a minute to bring down the entire node.

So what's the benefit to doing this instead of leaving PresenceSup as it
is, but just raising its limit to 10 times a minute (or more)?

In terms of your supervision strategy, not a lot. I can understand the
need for synchronization, but if you make that standalone application
have similar limits as the supervisor you'd put it under, it sounds like
you wouldn't lose a lot.

Is it otherwise a question of being able to control these limits
remotely (from another app), or specifying other arguments to be used?
I'm not sure I even understand the point for controlling supervision in
many cases. You just added one more layer that needs failing many times,
but little more.

In a previous e-mail, Ulf Wiger mentioned some of the original cases:


> Included applications were mainly introduced since the same
> call-handling applications needed to move as one during failover and
> takeover, and starting a dozen or so top applications made that much
> more difficult. It was just too much code and too many modules to
> integrate into one single application without one more structuring
> layer.

That's also why start phases were used. For single nodes, I'm not sure a
good use case even exists in terms of what the purposes of included
applications were.

Then again, you know I love debating included applications with you.


More information about the erlang-questions mailing list