例外処理

概要

ディベロッパーのコードで処理されない例外は、常に未処理例外イベントハンドラーを発生させます。
弊社は、未処理例外ハンドラーを実装するようディベロッパーに推奨しています。しかし、すべての場合において未処理例外はPhotonによってログされます。
詳細は、「未処理例外のロギング」を参照してください。
Photonは未処理例外が発生すると、以下の2つのポリシーのいずれかをサポートします：Ignore と TerminateProcess です。

一部のケースでは、例外処理ポリシーよりもCLRが優先される可能性があります、たとえば：

• ThreadAbortException は必ずしもプロセスを再起動または終了しませんー Exceptions in Managed Threadsを参照してください。
• StackOverflowException　は無視できませんー StackOverflowException Classを参照してください。

Photon 5.0での新機能

「ReloadAppDomain」ポリシーは旧形式となり、「Runtime」ノードの「UnhandledExceptionPolicy」値としてはもうサポートされていません。
何も指定されない場合には、「TerminateProcess」がデフォルト値となります。また、この値はSDKに配信される設定ファイル内に設定される値となります。

UnhandledExceptionPolicies使用の提案

「Exceptions in Managed Threads」からの以下の引用のとおり、Microsoftは「TerminateProcess」を.NET 2.0での新たなデフォルトポリシーとして導入しました。

スレッドの暗黙的な失敗が許可されている場合、 アプリケーションを終了しないと深刻なプログラミングの問題を検出できない場合があります。 これは長時間実行されるサービスや他のアプリケーション固有の問題です。スレッドが失敗すると、プログラムの状態は徐々に破損します。 これによって、アプリケーションのパフォーマンスが低下したり、 アプリケーションがハングアップすることがあります。

オペレーティングシステムがプログラムを終了するまでに未処理の例外をスレッドで自然に進行させると、開発およびテスト中にこのような問題が発生します。
プログラム終了のエラーレポートは、デバッグをサポートしています。

ただし、プロジェクトの段階や状況（開発中、QA中、既知の問題がなく本番で稼働中など）に応じて、Photonがサポートする様々なポリシーのいずれかを適用すると良いかもしれません。

• Ignore
• TerminateProcess

開発

開発中に「TerminateProcess」を設定すると、処理終了中にデバッガ/visual studioが起動します。
マルチスレッド問題を処理する場合には、処理を実行し続けてアプリケーションを読み込んでから、ポリシー「Ignore」を適用したほうがよいでしょう。

QA

QA段階の場合には、負荷テストや手動テストの際に「TerminateProcess」を使用すればルートエラーに起因する多くのエラーを受信せずにすみます。

本番環境で安定して稼働

サービスが安定している場合に、適用を考慮できるポリシーは「Ignore」です。
稀に発生する未処理例外のイベントによって、Photonはアプリケーションを再起動し、リスクを最小化します。
これが、システムの再稼動を最短で実現するための方法です。
「TerminateProcess」 ポリシーでPhotonをサービスとしてセットアップし、またWindowsサービス機能を自動的に再起動するよりも早く再起動できます。

注： この事象がより頻繁に発生する場合には、サービスおよびログファイルを監視する必要があります。

既知の問題があり、本番環境で稼動

システムが予期せぬ例外を頻繁に表示し、修正に時間を要する場合ー例外の内容によりますが、ポリシーを「Ignore」に設定すればシステムの安定性を維持できる場合があります。

StackOverflowsについての注

通常、未処理の例外の際にログを記録されたスタックトレースによって、修正すべき点を把握できます。
StackOverflowException とは、未処理の例外のポリシーが「Ignore」に設定されて、スタックトレースが欠損した可能性がある状態を指します。
デバッグの手順については、「Photon ServerのStackoverflow」ページを参照してください。

コアのデバッグについての注

稀に、Photonコアによって予期せぬ例外が発生する場合があります。この場合には、設定「ProduceDump」をTRUEに設定してください
（Photon Coreのデバッグを参照してください）。
生成されたダンプファイルとログを弊社に送信いただければ、問題の修正に役立つ場合があります。

未処理例外のロギング

下図に示したとおり未処理例外イベントは、まずカスタムアプリケーションのコンテキスト(1)で発生します。ディベロッパーは希望する方法で、 例外をc)にロギングできます。 また、ロードバランシングのサンプルコードも参照できます。
次のステップで、CLRはデフォルトのアプリケーションドメインでイベントを発生させます(2)。ーこれは、Photonの場合はPhotonHostRuntimeです。このためPhotonは、b)に例外をログすることができます。

Photonログファイルのデフォルトパス/ファイル名：

• a) [$PhotonBaseDir]\bin_[$OS]\log\Photon-[$InstanceName]-[$date].log
• b) [$PhotonBaseDir]\bin_[$OS]\log\PhotonCLR.log
• c) [$PhotonBaseDir]\log\[$ApplicationName].log

UnhandledExceptionポリシーの設定

XML

    <Runtime
      Assembly="PhotonHostRuntime, Culture=neutral"
      Type="PhotonHostRuntime.PhotonDomainManager"
      UnhandledExceptionPolicy="TerminateProcess"/>

• UnhandledExceptionPolicy: Ignore または TerminateProcess.

Photonコアのデバッグ

XML

   <!-- Instance settings -->
    <Instance1
        ...
        ProduceDumps = "TRUE"
        DumpType = "Full"
        MaxDumpsToProduce = "2"
        ...

サーバーがクラッシュし、その原因がログに残っていない場合、Photonはダンプファイルを作成するように設定することができます。
これらはクラッシュ時の状態やメモリを反映しており、このようなケースのデバッグには非常に有効です。

ダンプファイルが書き込まれたらログとともに圧縮し、問題の内容を記載のうえ問い合わせメールアドレスまで送信してください。
ほとんどの場合、弊社側でさらに多くの情報を収集し、問題解決のためにご連絡します

• ProduceDumps: TRUEまたはFALSE。クラッシュ時に、"ダンプファイル"作成の有効化/非有効化を切り替えます。
  ダンプファイルは、Photonコアの問題を発見するうえで不可欠です。
• DumpType: 書き込むクラッシュダンプのタイプを定義します。
  タイプはFull、Maxi、Miniのいずれかで、最初から最後まで少ない情報しか含まれていませんが、ストレージ容量は少なくて済みます。
• MaxDumpsToProduce: 最大何個のダンプファイルを書き込むかを設定します。
  ファイルが移動または削除されても、新しいファイルを書き込むことができます。
• MaxDumpsToAttemptToProduce: ダンプファイル作成の最大試行回数を設定します。

Back to top