[erlang-questions] Dependencies, included applications and supervision

[Fred Hebert]

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]
     /  |  \
    [[[Workers]]]

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:

        [AppSup]-------------->[PresenceSup]
         /    \                        |
     [SubSup] [SomeWorker]         [Server]
     /  |  \
    [[[Workers]]]

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:

http://erlang.org/pipermail/erlang-questions/2010-September/053594.html

> 
> 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.

Regards,
Fred.