[erlang-questions] Reusing servers in a new supervision tree
Wed Apr 9 18:35:55 CEST 2014
You could have two applications as you propose, in which case it might be useful to actually have three of them: one that just loads the common code, and the other two setting up the supervisor trees and depending on the first one.
Another approach is to write the supervisor something like the following, and set the application key 'test_mode' to the desired value for your environment.
case application:get_env(test_mode) of
true -> init_test(Args);
_ -> init_production(Args)
(Or generalize suitably.)
Option 3: use supervisor:start_child and supervisor:terminate_child to dynamically start and stop supervised processes. Have a look at the man page for more ideas: http://www.erlang.org/doc/man/supervisor.html
Finally, another option might be to have a look at gen_app (https://github.com/thomasl/gen_app) for easy assembly of (basic) supervisor trees. That could be sufficient for your testing purposes.
On Wednesday, April 9, 2014 12:39 PM, David Welton <davidnwelton@REDACTED> wrote:
>We have a supervision tree that seems to be working well and we are
>happy with. However, now we need to be able to put the system in
>"testing" mode, where, instead of a tree that has FSM A, and servers
>B, C, D, E and F, we only have a tree with B, D, and F.
>I don't think it's particularly important to be able to do this all
>that smoothly or cleanly: we can probably even restart the machine to
>put it in testing mode, or something like that - it's not a
>configuration where we have any kind of stringent uptime requirements!
>My idea is to actually have a separate application, say testing_mode
>that has a testing_mode_sup that directly starts B, D, and F. Can I
>do that across applications, though? Should I include the testing
>mode sup in the same application as the other stuff? We had some
>hopes of keeping it separate so that various additional testing mode
>pieces could be developed and distributed separately from the main
>bunch of code.
>Thank you for your thoughts,
>David N. Welton
>erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions