[erlang-questions] Re: non-trivial supervisor idioms?
Wed Sep 29 08:25:14 CEST 2010
I haven't personally come across a situation where I thought to my self
"I need to use included applications". After many discussions over these
sort of things in the company (related to release handling really) I
have more or less settled on one way of doing things. It seems to work
in all situations so far and is well suited for maintenance, release
upgrades and fail-over scenarios. Without going into a mile long post
and forcing myself to write a TLDR in the end I usually do things this
way: All applications are attached one level under the main top
supervisor; no included applications, only dependencies.
Each application is either a service, glue/logic or library application.
A service application is mnesia for example; using mnesia you _request_
it to create a table... etc. The library applications are just that
libraries, _usually_ static with no processes. Glue/Logic applications
are the ones which are actually the crux here. I usually design the
applications in a way that they are tolerant to restarts at any point
I.e: You should be able to do application:stop(App) and the chain of
events should stop waiting for the application to come back up again.
Ok so with this in mind imagine this scenario: I start my application
and it has mnesia in included_applications. my application then starts
mnesia, mnesia initializes its tables and returns, my application then
checks that all the tables are there and continue. In this case, if you
do application:stop(App) you shut down mnesia. All this works if the
release is centered around my application, that is I only have 1 which
is the "master application" and that imo is wrong. Note that in any case
you check that tables are available and not corrupt or what ever you
need to check. Now if you want to build another application or
extend/maintain/fix/whatever then you have to move mnesia back out again
(because you can't have another application relying on my application to
keep mnesia up). This in turns forces me to change my application to
make sure to check for mnesia is running and have tables at start up
(which I already have anyway). Now if I skip the first step and always
do my design in the latter mentioned way (because change always comes) I
will have saved a part of re-factoring (and also part of refactoring the
design). I can add App2 in the next release without worrying too much
about my first app being abused by to many changes. Also if let's say
mnesia crashes, then both my apps crash, but since you design your apps
to be able to crash at any point (Take inconsistent states into account
when bouncing up) they should be fine because they will be prepared on
startup to wait for resources/services (like mnesia).
So in the end it is a win-win (imho) to never use included_applications :)
I'm not claiming this is the *most* "OTP"-way to do it or that any other
way is necessarily wrong but some things in OTP you don't use that often
and I haven't found a need to use this. (btw I would love to hear from
someone who has experience with distributed applications, how did that
You write that "I have a situation where any issues will allow the node
to behave in a controlled way" but is it in a situation where the
applications which are included are only used by your main application?
I'm curious in what you see is the gain over having the application
processes "flat" under the top application supervisor.
On 28/09/2010 16:18, Steve Davis wrote:
> Hi Mazen,
> I understand your rationale, but I'm not so sure it's a cause for
> concern. The node/application is entirely dependent on the
> availability of those "generic" apps. By putting all parts of the app
> under one supervisor I have a situation where any issues will allow
> the node to behave in a controlled way. I believe that the approach of
> a single top-level supervisor for the app and dependencies is
> definitely an "OTP" thing to do. Possibly the only drawback is that it
> uses undocumented APIs (the sups) from libraries in the platform.
> However, I'm interested in further thoughts from yourself or others on
> this point.
> On Sep 28, 1:05 am, Mazen Harake<mazen.har...@REDACTED>
>> I'm not sure this is a good idea imho, I think included applications are
>> meant to be used for your own specific applications only and not the
>> generic ones like mnesia, crypto etc. I could be wrong but doing it the
>> way you described just feels wrong.
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
More information about the erlang-questions