ここ StackOverflow では、毎日いくつかの「リクエストのタイムアウト」例外が発生しています。
事実：
サーバーベースのタイムアウト (Thread.Sleep を使用) をテストしたところ、すべてのフォーム変数が例外ログに正しくキャプチャされました。
この状態をトラップ/デバッグする方法についての考えは大歓迎です!
小さな AJAX Web サービスを使用する運用サーバーでも同じ問題が発生しました。ファイアウォールの外側でパケット キャプチャを行った後、サービスへの POST が 2 つの TCP セグメントで送信され、2 番目のセグメントが受信されないことがわかりました。(最初のパケットにはヘッダーのみが含まれ、2 番目に欠落しているパケットは json 本体である必要があります) したがって、基本的に IIS はそこに座って残りの POST を待機しています。構成されたタイムアウトの後、サーバーは RST パケットをクライアントに送信し、「要求がタイムアウトしました」というエラーをログに記録します。これは正しい動作です。
あまり運が良くないクライアントの再現を取得しようとしていますが、私たちの場合、これは完全にネットワークに関連しているようです (または、投稿の内容を好まない「セキュリティ」ソフトウェア)。
IIS 7 を実行している場合は、Failed Request Tracingを使用できます。私は実際にタイムアウトに使用したことはありません。ほとんどの場合、特定の http エラー コードだけをキャプチャするように設定しました。しかし、X時間以上かかるリクエストのトレースをダンプできることは知っています。
telnet 経由で手動で投稿しようとしましたが、単に POST を完了できませんでしたか? 表示されている動作を再現できるかどうかを確認したいと思います。このサイトの性質を考えると、システムをハッキングしようとして意図的に不正な形式の POST をいくつか受け取ったとしても、私は驚かないでしょう。
何らかのアクションがハングした後、SO を再び機能させるために Safari を再起動する必要があることに時々気付きましたが、それは私の問題だと思いました。
この記事では、windbg を使用してこれをキャッチする方法について説明します。
非常にトラフィックの多い Web クライアントでこれらの現象をよく見ていましたが、それが関係しているのでしょうか。おそらく起こっていたのは、HttpWebRequest（HttpWebResponseに問題があると思いますか？おそらく同じ問題があると思います）は、リクエストが同期している場合でも、カバーの下でジャンクスレッドプールを使用しています。スタックの上位にある他の .NET オブジェクトが同じシステム スレッドプールを使用していて、一方が他方を枯渇させ、最終的にタイムアウトが発生したため、時々何かがデッドロックすることがありました。この問題については、 http ://www.deez.info/sengelha/2005/03/03/beware-threadpools-and-httpwebrequest/ で詳しく説明されていると思います。
また、ログの IP アドレスをスキャンして、同じ人が繰り返し問題を抱えているかどうかを確認します。ダイアルアップ アカウントをまだ使用しているユーザーがいる可能性や、別のネットワークの問題が発生している可能性があります。しかし、もちろん、できる限り調査せずにただ書き留めてはいけません。