[erlang-questions] Application startup order in a release

dmitry kolesnikov <>
Sat Jan 5 09:29:58 CET 2013


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 <> 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
> 
> http://erlang.org/mailman/listinfo/erlang-questions



More information about the erlang-questions mailing list