スケジュールされた時間にメールを送信するアプリケーションがあります。メールの送信中にアプリケーションが停止することがありますが、その理由はまだわかりません。
次のような単純なウォッチドッグを実装することを考えました。アプリケーションが電子メールの送信を開始する前に、ウォッチドッグの新しいインスタンスを初期化します。このインスタンスは、1 回限りのタイマーを開始します。タスクが正常に完了すると、ウォッチドッグに停止する必要があることを知らせ、タイマーをキャンセルします。タイマーで定義された期間が経過した場合、プログラムを強制的に終了します。
これが有効な解決策なのか、それともハックのようなものなのかはわかりませんが、この件に関するご意見をいただければ幸いです。
ありがとう、オマー
それはそれほど悪い考えではありません。
ここで見られる主な落とし穴は技術的なものではなく、人道的なものです。ウォッチドッグが機能し、適切に機能し、顧客が文句を言わなくなったら、「問題は解決しました!」と簡単に言うことができます。元の問題を忘れます (せいぜいバックログに放り込み、最悪の場合「解決済み」としてマークします)。
技術面では:
ウォッチドッグとアプリケーションの分離レベル、およびウォッチドッグのアクションがどれほど激しいかを検討する必要がある場合があります。最小限の分離は、ウォッチドッグを別のスレッドで実行することです (ワンタイム タイマーがそれを行います)。電子メール メカニズムとウォッチドッグを異なる AppDomain で実行する方がよい場合があります。そのため、ウォッチドッグはタイムアウト時に「電子メール AppDomain」全体をアンロードします。これにより、プロセスを強制終了するのと同様の解決策が得られますが (少なくとも「管理された」観点では)、プロセスを強制終了して再度開始するよりも暴力的ではありません。
競合状態についても考慮する必要があります。ウォッチドッグのタイマーと電子メール送信プロセスが競合しているため、電子メールが正常に送信された後にプロセスが強制終了される可能性があります。アプリケーション (これは、カスタマー エクスペリエンスの低下につながります)。
コメンテーターが言うように、問題をデバッグすることを強くお勧めします。トレース、ロギング、生産時のデバッガー (WinDbg など) などの生産デバッグ ツールと機器を使用して、再現不可能な問題を診断およびデバッグできるようにする必要があります。