11 月 24 日に SEOTcs システムが SEO スコアリング アルゴリズムを更新して以来、Java データ ジョブ タスクの実行中に次のエラーが頻繁に報告されるようになりました。
「2011-12-03 18:00:32 DefaultHttpClient [情報] リクエストの処理中に I/O 例外 (java.net.SocketException) が捕捉されました: ピアによって接続がリセットされました: ソケット書き込みエラー
2011-12-03 18:00:32 DefaultHttpClient [情報] リクエストを再試行しています」…
このために、中国語と英語の Web サイトを隅々まで調べ、この Java 例外がクライアント側とサーバー側の両方で発生する原因を見つけました。 2 つの理由:
1. 一方の端のソケットが閉じられている (またはアクティブに閉じられている、または異常終了により閉じられている) 場合でも、もう一方の端は引き続きデータを送信し、送信された最初のデータ パケットがこの例外をトリガーします (ピアによる接続リセット)。
2. 一方の端が終了しますが、終了時に接続が閉じられていない場合は、例外 (接続のリセット) がスローされます。簡単に言えば、接続が切断された後の読み取りおよび書き込み操作によって発生します。
そこで、ソケットタイムアウトを設定することで解決できるのではないかと単純に考えました。
しかし、セットアップ後も状況は同じです。
私はこの問題に数日間悩まされており、この問題を引き起こしたコードを見つけるために、同じキーワードの数を前提として、なぜなのかを考えずにはいられず、毎日比較テストを行ってきました。以前のバッチ クエリのランキング データにはエラーはありませんでしたが、最近エラーが頻繁に報告されています。これはなぜですか?要求されたインターフェイス Web サイトがサーバー IP をブロックしていますか?この理由は十分ではありません。プログラムのどこかで接続を適切に解放できなかったことが原因であるはずです。
この考えに基づいて、数日間の継続的な努力と練習を経て、今日、ついにタイマー方式によって引き起こされる問題の本質を発見しました。状況は次のようなものです。過去数日間、いくつかのバッチタスクを手動でトリガーしたところ、フィルターのランキング値が100の場合、エラーjava.net.SocketException：javaの接続リセットがスローされ続け、画面が表示されることがわかりました。このタイマーのコードを注意深く比較した後、リフレッシュは特に強力です。
ようやく、ハッと気づきました、そうだ！ここに問題があるので、自分で分析してみましょう。
関数の値、返される値はクリティカルな値ですが、私のタイマーメソッドでは、返された値がクリティカルな値であると判断され、10秒以内にそのメソッドの実行を強制的に継続します。このメソッドは、ページ内のソース コードの特定のデータを取得するには、このメソッドを実行するたびに数十ミリ秒かかります。これは、ビルドに相当する時間です。ソケット接続は確立されますが、常にクリティカル値を返すため、このメソッドはデータを取得するために 10 秒以内に継続的にソケット接続を確立します。このメソッドを毎回実行すると、約 80ms かかります (テスト後、毎回の実行時間)。このようなメソッドの時間は約 80 ミリ秒です)、10 秒以内に 10*1000/80 が作成されます。 = 125 ソケット接続、つまり 1 秒あたり 12.5 ソケット接続が確立されます。また、これはフィルタリング プログラムであるため、複数の重要な値が連続して表示されます。同じ Web サイトのページでも、数が非常に急増し、数百、さらには数千に達し、処理を待機しているリクエスト接続の数が過剰になります。
そもそもなぜタイマー方式でメソッドを複数回実行したのかというと、その理由は安定したデータの値を取得するためだったのですが、今考えるとそのマイナスの影響は軽視できません。 , しかし、数日間にわたる包括的な分析とテストの後、最終的に犯人が発見されました。問題が解決された後、私の心は突然安らぎ、穏やかに眠ることができました。 。 。