[erlang-questions] prep_stop in an included application

[Alex Vazquez]

2009/5/21 Ulf Wiger <ulf.wiger@REDACTED>

> Alex Vazquez wrote:
>
>>
>> Anyway, just for curiosity, there would be any reason preventing some
>>  kind of stop_phases scheme or it's just that nobody found it that
>> necessary and/or had the time to do it?
>>
>
> Others may remember it differently, but this is my recollection.
>
> Back in 1996, when the AXD 301 project got started using the
> very first version of OTP, we fairly quickly ran into some
> problems. For sure, we had a very complex product to write*
> but we also had many more people than one would wish for in
> a first iteration of the system.
>
> * Piling the initial specifications on top of each other,
> they measured about 3 ft.
>
> One consequence was that we ended up with multiple teams
> working on the same application. To manage this, we split
> the application into sub-applications and wrote a build tool
> to merge them into one big .app file. This was the precursor
> to included applications.
>
> We also found that it was very difficult to manage the start
> sequence of applications with several processes and complex
> dependencies during initialization. After a period of writing
> messy code with processes casting to themselves and then
> rushing to get all the work done before someone thought to
> start using the APIs, we developed a form of start phases
> through use of environment variables (as I described previously)
> and a central start function.
>
> These two things eventually made it into OTP, in a slightly
> modified form. At the same time, AFAIR, the application
> behaviour was invented. By this time, OTP was used in several
> other projects, and it was reasoned that since the
> implementation meant that /any/ application could be made
> included just by adding it to the 'included_applications'
> attribute of another application**, it might not always
> be a good idea to call the original start functions etc.
> If the application had been designed under the assumption
> that it was a "top-level application", it might end up
> doing things that were not appropriate under the given
> circumstances.
>
> ** This was actually another requirement from the AXD
> project, since we wanted to be able to include applications
> such as snmp, inets, etc. The reason for this was that we
> needed them to move together with other O&M components
> during failover and takeover. Many years later, we invented
> ways to handle the synchronized switchover without bundling
> everything into one app.
>
> Much later, we observed that it could also be quite problematic
> to stop these complex applications, and that some form of phased
> shutdown would sometimes be useful. That's when the prep_stop
> phase was invented. It was reasonable to give it similar
> semantics to the start, start phases, and stop callbacks.
>
> Does that satisfy your curiosity?
>

I thank you the vast explanation, Ulf.

What sounds weird to me is the fact that start_phases are run for all
included applications while prep_stop is only run for the primary
application (Am i wrong in this assumption?). I was asking if this behaviour
has some reason that i'm unaware of, but, again, thank you for the info.

Regards,


> BR,
> Ulf W
>
> --
> Ulf Wiger
> CTO, Erlang Training & Consulting Ltd
> http://www.erlang-consulting.com
>



-- 
Alejandro Vazquez Fente
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090521/57aa9f61/attachment.htm>