3

我试图了解这里发生了什么：

我有一个主管在不触发MaxR, MaxT机制的情况下循环重启一个客户端。客户端只是缓慢地崩溃，永远不会触发速率限制。

将有另一种机制使用supervisor:which_children/1并delete_child/2, start_child/2调整子集以适应现实（它扫描 USB 设备，试图让每个设备找到一个监督子）。

这通常表现为速率限制的安全网，但奇怪的是，它看起来根本没有调用删除和启动子项的机制。

为了找出发生了什么，我supervisor:which_children/1从 shell 调用，看起来调用只是阻塞并且永远不会返回。

是否会在它忙于尝试重新启动孩子时阻止对主管的呼叫？

附录：

看起来崩溃发生在子启动期间：

=SUPERVISOR REPORT==== 29-Mar-2011::21:36:20 ===
     Supervisor: {local,gateway_sup}
     Context:    start_error
     Reason:     {'EXIT',{timeout,{gen_server,call,[<0.155.0>,late_init]}}}
     Offender:   [{pid,<0.76.0>},
              {name,gw_3_5},
              {mfa,{channel,start_link,
                            [[{gateways,[{left,108},{right,103}]}],
                             {3,5}]}},
              {restart_type,transient},
              {shutdown,10000},
              {child_type,worker}]
4

1 回答 1

2

除了讨论之外，问题的答案是：

当重启一个在启动过程中失败的子进程时，监督者在它的进程内部循环（它在内部是一个 gen_server），而不是处理对它的任何 API 调用。

因此，如果将主管的速率限制配置为不会在子项的启动错误时触发，则尤其糟糕。在我的示例中，我的启动速度很慢（尤其是在出错时）。

因此，如果主管永远循环试图重新启动一个孩子，那么任何对它的调用都无法访问......这通常很糟糕。

于 2011-03-30T14:28:58.390 回答