[erlang-questions] Application startup order in a release

[Karolis Petrauskas]

Hello,

    I have:
{application, 'Core', [
    ...
    {applications, []},
    ...
]}
{application, 'Plugin1', [
    ...
    {applications, ['Core', 'Lib1']},
    ...
]}
{application, 'Worker1', [
    ...
    {applications, ['Core']},
    ...
]}

    The dependencies in this case do not define, which application
should be started first, Plugin1 or Worker1. Is it enough to specify
these applications in an appropriate order in the reltool.config (in
order to be sure, that the Plugin1 will be started before Worker1)?,
i.e.
{sys, [
    ...
    {rel, "my_rel", "1", [
        ....
        Core, Plugin1, Worker1
    ]},
    ...
]}

    Or maybe there are other configuration options in the
reltool.config to specify application startup order? I experimented
with the rel option in the reltool.config a bit. It looks like the
applications are started in the specified order, except that the order
is adjusted to satisfy the dependencies (applications option) in the
application resource files. But I am not sure, if that was just lucky
case, or the system is guaranteed to work so.

Karolis
On Sat, Jan 5, 2013 at 10:29 AM, dmitry kolesnikov
<dmkolesnikov@REDACTED> wrote:
> Hello,
>
> Basically you are assembling a release out of many applications. You
> have to define a relconfig file. It defines all application and they
> start up order.
> Once config is defined you can generate a release ./rebar generate
>
> Best Regards,
> Dmitry >-|-|-*>
>
>
> On 5.1.2013, at 1.25, Karolis Petrauskas <k.petrauskas@REDACTED> wrote:
>
>> Hello,
>>
>>    My Erlang based system is composed of several applications.The
>> applications can be classified to Core, Plugins and Workers. All
>> Plugins and Workers have static dependencies on the Core only. I.e
>> Plugin and Worker application modules use modules from the Core, and
>> have the application Core listed in their *.app files. The Core
>> application provides several behaviours and process registries.
>> Plugins are providing callback modules for these behaviours and
>> registers corresponding processes to the registries. The Worker
>> applications use behaviours defined in the Core and use the registries
>> to lookup the needed processes. That way the Worker applications can
>> use Plugin processes without knowing about them in advance (behaviours
>> are used as interface definitions).
>>    I am using sys.config to wire-up all the system (telling Workers
>> which Plugin-provided processes to use by specifying process names).
>> That way I am getting runtime dependencies between the corresponding
>> Workers and Plugins. The corresponding Plugins should be started
>> before the Workers that have run-time dependencies on them.
>>    I am generating release (using rebar) to run my system. As I
>> understand, the applications are started according to their
>> application dependencies, as listed in the .app files. Here is my
>> question: how can I control application startup order in the release
>> without including corresponding Plugin applications into the *.app
>> files of the Workers? I want to keep the Worker applications as clean
>> as possible. Is there a way to control the startup order during
>> generation of the release? The only option I know is to transform the
>> application files after they are build (rebar compile) and before the
>> release is generated (rebar generate). But that sounds hacky. Maybe
>> there are better options or maybe my approach on managing application
>> dependencies is wrong?
>>
>>    For example, the static dependencies are the following:
>> Plugin1 -> Core, Lib1
>> Plugin2 -> Core, Lib2, Lib3
>> Worker1-> Core
>> Worker2-> Core
>>
>>    The Lib1, 2, 3 are other applications (e.g. Yaws). They are not
>> needed by Workers till the run-time. Even integration tests
>> (common-test) can be executed without them. But for the production
>> system the following dependencies should be added (or at least the
>> corresponding startup order enforced):
>> Worker1 -> Plugin1, Plugin2
>> Worker2 -> Plugin1
>>
>> Karolis
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions