私が覚えている限りでは、ロール インスタンスはクラッシュ/障害の後に自動的に再起動を実行する必要があります。その動作をテストするために、メモリ不足の例外を強制するアプリケーションを作成しましたが、アプリケーションがクラッシュしました。ロール インスタンスは再起動を実行しませんでした。これは、まだ実行中で問題がなかったからです。インスタンスは .NET ランタイムを再起動しただけです。
インスタンスがさまざまなエラーにどのように反応するかを調べようとしています。私の場合、再起動は必要ありませんでした。インスタンスの完全な再起動の原因となる (強制できる) エラー/例外のタイプは? インスタンスを永久に強制終了するエラー/例外のタイプは何ですか?
ロール インスタンスがリサイクル (再起動) される唯一の理由は、 RoleEntryPointのRunメソッドが終了したときです。これは通常、次の場合に発生します。
ただし、IntelliTrace ログ収集を有効にすると、ロールはリサイクルされますが、ハングします。
WebRole の既定のテンプレートはRun()メソッドをオーバーライドしないため、既定の実装である "Thread.Sleep(-1);" が残されます。WebRole の自動ロール リサイクルを引き起こす (自動) イベントはありません。RoleEntryPoint で何かを行わない限り、Run メソッドが終了します。この自動リサイクルは、Run() メソッドを実装する WorkerRole でのみ発生します。
UPDATE 1（コメント1による）
run-Methoded of a RoleEntryPoint faces an error
単なるエラーではなく、Run() メソッドを終了させるような種類のエラー (未処理の例外) です。
さらに、WebRole で Run() をオーバーライドすることはできません。これは、RoleEntryPoint の子孫が Web アプリケーションとは異なるアプリ ドメイン (異なるプロセスであっても) にあるためです (そのため、アプリケーションの例外についてはわかりません)。フル IIS ホスティングとプロセスの詳細については、こちらをご覧ください。
したがって、Web ロールの場合、IIS 7.0 / 7.5 を完全に備えた Web アプリケーションを使用するだけで、この IIS が Azure 展開の一部であることがわかりません。Global.asax は、ASP.NET で未処理の Web アプリケーション エラーを管理する場所です。この質問を確認してください。その答えは、Application_Error() ハンドラーの良い例です。
RoleEnvironment タイプのRequestRecycle静的メソッドを使用して、Application_Error() メソッドでロールの再利用を手動で要求できます。ただし、そうすることはお勧めしません。アプリケーション エラーが原因で、Web サーバーを再起動することはお勧めできません。優れた例外処理とエラー ロギング戦略を実装し、エラー ログを定期的に調べて、サーバーの再起動が必要になる重大なエラーを回避するための措置を講じる必要があります。
本来の意図は？ロールがいつ自動的にリサイクルされるかを理解したり、エラー時にロールを自動的にリサイクルするようにアプリケーションをモデル化したりするには? 後者の場合は、ビジネス要件/ロジックを修正することをお勧めします。
更新 2
ニールの口からは言えませんが、「インスタンスの障害」は、実行中の VM がハングする原因となるすべてのものです。Windows Azure のインスタンスは、アプリケーションのコードをホストする単一の仮想マシンです (このブログ投稿をお読みください)Hosted Service、Role、Instance の詳細な説明について)。アプリケーションは、Windows Server ベースの OS で実行されます。仮想マシンです。ホストのハードウェア障害から、ゲスト OS の一般的なソフトウェア/ドライバーの障害まで、あらゆることが発生する可能性があります。あなたのコードである必要はありません。そのため、単一の VM で障害が発生するような事態が発生した場合、この問題は Windows Azure ファブリックによって自動的に処理されます。必要に応じて、コードは別の仮想マシンに自動的にデプロイされます。そして、これは自動的に起こります。あなたは何もしません。HDD の破損、メモリ モジュールの焼損、またはネットワーク インターフェイスの応答停止を想像してみてください。これらは、実行中の VM に障害が発生する可能性があるいくつかの単純な問題です。これはインスタンス障害です。
コードの失敗は、対処する必要があるものです。その他すべて - Windows Azure ファブリック コントローラーが処理します。
更新 3
- 例外が発生し、それが処理されない場合、webrole の asp.net アプリケーションはどうなりますか? アプリケーションは、探すまで未定義の状態 (「壊れた」) でハングするだけですか、それとも vm によって終了されますか?
この質問は完全に範囲外です。共有ホスティング アカウントの asp.net アプリケーションはどうなりますか? それとも、オンプレミスの IIS インストールでしょうか? アクションがクラッシュの原因となったユーザーのアプリケーション クラッシュ。最悪の場合のアプリ プールのリサイクル。「ハングした」asp.netアプリケーションを見たことがありません。「asp.net アプリケーションが終了した」または「壊れた」というようなことはありません。アプリケーションの起動中または最初のリクエスト中に発生した一般的なエラーの場合、アプリケーションはオンラインになりません。一連のユーザー アクションによって発生したエラーの場合、Global.asax に適切な Application_Error() ハンドラーがない限り、ユーザーには見苦しいエラー メッセージが表示され、それ以上は何も表示されません。アズールと。
- Web ロール全体のクラッシュを引き起こす可能性がある、または (.NET の未知のバグを除いて) マネージ コードでは不可能な、私のアプリケーション内の .NET コードの一部を考えられますか?
冗談ですか？このコードは Web ロールをクラッシュさせ、リサイクルを強制します。
RoleEnvironment.RequestRecycle()
何かが欠けているとは思わないので、この質問を受け入れてください。さらに、元の質問に加えて、少なくとも 4 つの質問への回答が追加されています。
最後の
「インスタンスを永遠に殺す」というようなことはありません。