【问题标题】:Erlang supervisor termination behaviorErlang 主管终止行为
【发布时间】:2014-06-03 05:36:13
【问题描述】:

我有一个可能是不寻常的情况,一个启动 2 个顶级主管的应用程序,例如,

...
-behavior(application).
...
start(_StartType, _StartArgs) ->
    sup1:start_link(),
    sup2:start_link().

他们都有{one_for_one, 0, 1} 重启策略。他们的孩子实现了一个简单的 crash 函数,该函数会引发 bad_match 错误。

对于我的问题,如果我调用 sup1_child1:crash() 主管 sup1 将终止但应用程序将继续运行(即主管 sup2 及其子级仍然可用)。相反,如果我调用sup2_child1:crash(),则整个应用程序将终止。后一种行为是我在这两种情况下所期望的。如果我翻转 start_link() 调用的顺序,即

...
    sup2:start_link(),
    sup1:start_link().

然后崩溃 sup1 将导致应用程序终止,但崩溃 sup2 不会。所以看起来 start_link() 的调用顺序决定了哪个主管崩溃将导致应用程序终止。这是预期的吗?还是我通过拥有 2 个根监督者来滥用监督树功能?

谢谢,

丰富

【问题讨论】:

    标签: erlang terminate erlang-supervisor


    【解决方案1】:

    这完全在意料之中,并且是意料之中的因为您正在滥用监督树功能。有一个隐藏的监督者叫做“应用监督者”。您的 application:start 函数应该返回一个由应用程序主管监控的 SINGLE pid。如果该进程崩溃,BEAM VM 也会崩溃(实际上取决于应用程序的启动方式;与工作进程类似,您的应用程序可以是永久的或临时的(甚至可能是临时的)。

    您应该有一名顶级主管(您的应用程序主管)。如果您需要两个顶级主管,他们都应该是您的应用程序主管的子级。

    【讨论】:

    • 感谢您的解释。我又看了看,在Erlang OTP Principles Guide 中找到了这个语句 - start 在启动应用程序时被调用,并且应该通过启动顶级主管来创建监督树。期望返回最高主管的 pid 和一个可选的术语 State,默认为 []。这个词是按原样传递的。 和你说的差不多。再次感谢!
    猜你喜欢
    • 2012-11-16
    • 2016-08-09
    • 2014-05-19
    • 2014-11-29
    • 2011-08-07
    • 2016-01-04
    • 2015-08-22
    • 2017-05-02
    • 2014-07-10
    相关资源
    最近更新 更多