Pass some arguments to supervisor init function when app starts

Question

I want to pass some arguments to supervisor:init/1 function and it is desirable, that the application's interface was so:

redis_pool:start() % start all instances
redis_pool:start(Names) % start only given instances

Here is the application:

-module(redis_pool).
-behaviour(application).

...

start() -> % start without params
    application:ensure_started(?APP_NAME, transient).

start(Names) -> % start with some params
    % I want to pass Names to supervisor init function
    % in order to do that I have to bypass application:ensure_started
    % which is not GOOD :(
    application:load(?APP_NAME),
    case start(normal, [Names]) of
        {ok, _Pid} -> ok;
        {error, {already_started, _Pid}} -> ok
    end.

start(_StartType, StartArgs) ->
    redis_pool_sup:start_link(StartArgs).

Here is the supervisor:

init([]) ->
    {ok, Config} = get_config(),
    Names = proplists:get_keys(Config),
    init([Names]);
init([Names]) ->
    {ok, Config} = get_config(),
    PoolSpecs = lists:map(fun(Name) ->
        PoolName = pool_utils:name_for(Name),
        {[Host, Port, Db], PoolSize} = proplists:get_value(Name, Config),
        PoolArgs = [{name, {local, PoolName}},
                {worker_module, eredis},
                {size, PoolSize},
                {max_overflow, 0}],
        poolboy:child_spec(PoolName, PoolArgs, [Host, Port, Db])
    end, Names),
    {ok, {{one_for_one, 10000, 1}, PoolSpecs}}.

As you can see, current implementation is ugly and may be buggy. The question is how I can pass some arguments and start application and supervisor (with params who were given to start/1) ?

One option is to start application and run redis pools in two separate phases.

redis_pool:start(),
redis_pool:run([] | Names).

But what if I want to run supervisor children (redis pool) when my app starts?

Thank you.

Answer 1

The application callback Module:start/2 is not an API to call in order to start the application. It is called when the application is started by application:start/1,2. This means that overloading it to provide differing parameters is probably the wrong thing to do.

In particular, application:start will be called directly if someone adds your application as a dependency of theirs (in the foo.app file). At this point, they have no control over the parameters, since they come from your .app file, in the {mod, {Mod, Args}} term.

Some possible solutions:

Application Configuration File

Require that the parameters be in the application configuration file; you can retrieve them with application:get_env/2,3.

Don't start a supervisor

This means one of two things: becoming a library application (removing the {mod, Mod} term from your .app file) -- you don't need an application behaviour; or starting a dummy supervisor that does nothing.

Then, when someone wants to use your library, they can call an API to create the pool supervisor, and graft it into their supervision tree. This is what poolboy does with poolboy:child_spec.

Or, your application-level supervisor can be a normal supervisor, with no children by default, and you can provide an API to start children of that, via supervisor:start_child. This is (more or less) what cowboy does.

Answer 2

You can pass arguments in the AppDescr argument to application:load/1 (though its a mighty big tuple already...) as {mod, {Module, StartArgs}} according to the docs ("according to the docs" as in, I don't recall doing it this way myself, ever: http://www.erlang.org/doc/apps/kernel/application.html#load-1).

application:load({application, some_app, {mod, {Module, [Stuff]}}})

Without knowing anything about the internals of the application you're starting, its hard to say which way is best, but a common way to do this is to start up the application and then send it a message containing the data you want it to know.

You could make receipt of the message form tell the application to go through a configuration assertion procedure, so that the same message you send on startup is also the same sort of thing you would send it to reconfigure it on the fly. I find this more useful than one-shotting arguments on startup.

In any case, it is usually better to think in terms of starting something, then asking it to do something for you, than to try telling it everything in init parameters. This can be as simple as having it start up and wait for some message that will tell the listener to then spin up the supervisor the way you're trying to here -- isolated one step from the application inclusion issues RL mentioned in his answer.