Question

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

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

还有另一种机制使用supervisor:which_children/1和delete_child/2, start_child/2来使这组儿童适应现实（扫描USB设备试图找到每个设备有一个主管子）。

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

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

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

附录：

看起来在儿童开始时发生了崩溃：

=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}]

Answer 1

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

当重启启动期间失败的子进程时，超级用户在其进程内循环（内部是gen_server），不处理对它的任何API调用。

因此，如果配置了主管的速率限制，它将不会触发子节点的启动错误，这一点尤其糟糕。在我的例子中，我的启动速度很慢（特别是在出错时）。

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

主管是否在重启孩子时阻止呼叫？

1 个答案: