6

リモートサーバーへの接続を処理するTCPクライアントと接続プロトコルを処理するFSMの2つのワーカープロセスを持つスーパーバイザーがいます。

子プロセスでTCPエラーを処理すると、コードが大幅に複雑になります。したがって、「クラッシュさせる」ことをお勧めしますが、これには別の問題があります。サーバーに到達できない場合、再起動の最大数にすぐに到達し、スーパーバイザーがアプリケーション全体とともにクラッシュします。これは、この場合。

私が望んでいるのは、バックオフを使用した再起動戦略を立てることです。これに失敗した場合は、クラッシュが原因で再起動されたときにスーパーバイザーが認識していれば十分です（つまり、init関数にパラメーターとして渡された場合）。このメーリングリストのスレッドを見つけましたが、より公式でよりテストされたソリューションはありますか？

4

3 に答える 3

6

あなたは私たちのスーパーバイザークッションが良い出発点であると思うかもしれません。私はそれを使用して、実行する必要があるものの再起動を遅くしますが、起動時にすぐに失敗します（リソースの問題が発生しているポートなど）。

于 2010-09-24T19:03:55.853 に答える
6

私はerlangで何度もこの問題を抱えており、多くの解決策を試しました。私が見つけた最善の方法は、スーパーバイザーによって開始され、クラッシュする可能性のある追加のプロセスを開始することです。

起動時に子を起動し、子が終了するのを待って（遅延して）子を再起動するか、必要に応じて終了します。これは、1人の子に関する状態を保持するだけでよいため、（リンク先の）バックオフサーバーよりも簡単だと思います。

私が使用した別の解決策は、子プロセスを一時的なものとして開始し、クラッシュしたプロセスに対してポーリングして再起動を発行する別のプロセスを用意する必要があることです。

于 2010-09-24T10:17:12.463 に答える
2

process_flag(trap_exit, true)したがって、最初に、initでを使用して、子の早期終了をキャッチする必要があり ます。

次に、再起動をたとえば10秒遅らせる時間を決定する必要があります。これは、

handle_info({'EXIT', _Pid, Reason}, State) ->
    erlang:send_after(10000, self(), {die, Reason}),  
    {noreply, State};

最後に、プロセスを終了させます

handle_info({die, Reason}, State) ->
    {stop, Reason, State};
于 2017-12-27T17:45:46.967 に答える