[erlang-questions] Re: non-trivial supervisor idioms?

[Mazen Harake]

  Hi Steve,

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 
work out!?)

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.

/Mazen


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.
>
> Regards,
> Steve
>
> On Sep 28, 1:05 am, Mazen Harake<mazen.har...@REDACTED>
> wrote:
>> 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
>