0

クラウドで実行されている worker ロールがあり、Azure CloudQueue を定期的にポーリングして、Web ロールがそこに置いたメッセージを取得します。現在、ワーカー ロールと Web ロールは同じクラウド サービス アプリケーションに収容されており、現在は 1 つのインスタンスのみを実行しています。

テスト中はロギングをオンにしているため、メッセージの内容やその他の有用な情報がクラウド ストレージに表示され、Cerebrata Azure Diagnostics Manager を使用して表示されます。（ところで素晴らしい製品）

DiagnosticMonitorConfiguration diagConfig = DiagnosticMonitor.GetDefaultInitialConfiguration();

diagConfig.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;

実際にはすべてが非常にうまく機能しているように見えますが、トレース ログに "Fail" というメッセージだけの詳細メッセージが表示されることがあります。生成元と思われるコードは try キャッチでラップされているため、これらの方法でメッセージが表示されないのは奇妙です。

コードの制御が及ばない何かが発生しているように見えます。おそらくワーカー ロールが再起動されているか、クラウド オペレーション システムが、ワーカー ロールを再起動することによってのみ対処できる重大なエラーを検出しています。それは回復し続けているので、何が起こっているのかは私たちにはやや謎です.

まだ確認していないのは、メッセージを失っているかどうかです。

どんな助けでも感謝します。乾杯キンド マレー語

4

2 に答える 2

0

しばらく実行した後にロール インスタンスが再起動される場合は、多くの場合、未処理の例外が原因でプロセスが終了したことが原因です。

于 2010-10-07T21:04:27.797 に答える
0

スタック トレースがなければ、多くを語ることはできませんが、ロギングを詳細に設定すると、使用している dll の 1 つからの内部ロギングが表示される可能性が非常に高くなります。

たとえば、特定の種類のエラーを引き起こす Azure テーブル クエリを実行すると、エラーは 3 回ログアウトされます。これは、ストレージ クライアント ライブラリがエラーをキャッチし、トレースしてから再試行するためです。

エラーが try catch ブロックでキャッチされていない場合は、心配する必要はありません。

キュー メッセージの配信可能性が重要な場合は、CloudQueue.GetMessage の可視性タイムアウト オーバーロードを利用し、メッセージの処理が完了したときにのみメッセージを削除するようにしてください。一部のメッセージを 2 回処理することになる場合もありますが、少なくともすべてのメッセージを処理できます。

于 2010-10-07T19:27:21.560 に答える