3

ここで何が起こっているのかを理解しようとしています:

MaxR, MaxTメカニズムをトリガーせずに 1 つのクライアントを周期的に再起動しているスーパーバイザがいます。クライアントは、レート制限をトリガーしないほどゆっくりとクラッシュします。

supervisor:which_children/1子のセットを使用して実際に適応させる別のメカニズムがあったはずdelete_child/2, start_child/2です (USB デバイスをスキャンして、見つかったデバイスごとに 1 つのスーパーバイザーの子を持たせようとします)。

これは通常、レート制限に対するセーフティ ネットのように動作しますが、奇妙なことに、子を削除して開始するメカニズムがまったく呼び出されないように見えます。

何が起こっているのかを知るために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}]
4

1 に答える 1

2

議論以外の質問への答えは次のとおりです。

起動中に失敗した子を再起動すると、スーパーバイザーはそのプロセス内でループし (内部的には gen_server です)、API 呼び出しを処理しません。

そのため、スーパーバイザのレート制限が、子プロセスの起動エラーでトリガーされないように構成されている場合は、特に問題があります。私の例では、起動が遅い（特にエラー時）。

そのため、スーパーバイザが子を再起動しようとして永遠にループすると、その子への呼び出しに到達できなくなります...これは通常悪いことです。

于 2011-03-30T14:28:58.390 に答える