私は素晴らしい高速タスク スケジューリング コンポーネント (Windows サービスが発生しますが、これは無関係です) を持っています。これは、実行することのメモリ内キューをサブスクライブします。
キューは非常に高速に入力されます...そして、高速と言うときは高速を意味します...非常に高速であるため、特定の部分で問題が発生しています。
キュー内の各アイテムには「カテゴリ」が添付され、WCf エンドポイントに渡されて処理され、リモート データベースに保存されます。
これは少し問題を引き起こしています。
「キュー」は毎分数百万のアイテムで処理できますが、WCF エンドポイントは現実的には毎秒約 1000 から 1200 アイテムしか処理せず、スロットがそれらを db にダンプするのを待つためにそれらの多くは「スタック」されます。 .
私のWCFクライアントは、呼び出しが発生して忘れられるように（意図的に）構成されているため、呼び出しが時折行われるとタイムアウトが発生し、それが頭痛の種になるという問題があります。
スレッドは、タイムアウト後に停止しているように見えますが、キャッチブロックには何もドロップしません...ただそこに座っています。さらに混乱しているのは、これが断続的なものであることです。これは、キューが極端な負荷と WCF エンドポイントを処理している場合にのみ発生します過大に課税されており、そのシナリオでも、これが発生するのは 2 週間に 1 回程度です。
このコードは、24 時間 365 日、サーバー上で常に実行されています。
それで... 私の質問... 問題を解決できるように、問題の原因となっているエッジケースを特定するにはどうすればよいですか?
追加情報:
WCF エンドポイントを呼び出すクライアントは、呼び出しを行うスレッドの数を制限しているという事実によって、自動的に「自分自身を調整」するように見え、呼び出しが完了したと見なされるまでコードがハングアップします (これは http レベルのものだと考えています)。メソッド呼び出しの結果をサービスに要求していないため）。
データベースは、データベースへの固定数を超える接続を開くことは決してないように見えるEFと通信され（非常に低い数でもあり、クールです）、コール受信からのWCFエンドポイントは非常に信頼できるようです。
問題は、キュー プロセッサから WCF エンドポイントに送信されているようです。
キュー プロセッサには、すべての呼び出しで再利用する WCF エンドポイント クライアントの単一のインスタンスがあります (呼び出しごとにこのエンドポイントを再構築することをお勧めしますか? - ここでの呼び出しの数に注意してください)。
最後の注意:
それは機能の独特の「モジュール」であり、一度に何時間も重い負荷がかかっても安定していますが、何らかの理由でこの奇妙なことが起こり、すべてが停止して回復しません. 呼び出しは try catch でラップされていますが、一見、catch がヒットしても (これは保証されません)、コードは期待どおりに回復/ドロップアウトしません ... ただハングします。
何か案は？
この問題を解決するために追加できることが他にある場合はお知らせください。
編集1：
バインディング - basicHttpBinding
エラー処理 - WCF 呼び出しを try キャッチでラップする以外のコードは記述されていません。