0

私たちの製品サーバーでは、外部サービスへのリクエストがタイムアウトして失敗することがよくあります。これに先立って、短い応答時間が長くなります。興味深いことに、同じサービス (Apple Purchase および/または Facebook) を呼び出す同一のサーバーの配列があり、ノードの 1 つだけが長い応答時間に悩まされています。したがって、サービスが遅いだけではありません。この問題はめったに発生せず、再現が困難ですが、それでも非常に懸念されます。

ノードのスレッド数とメモリ数は正常に見え、タイムアウトだけの例外はありません。Java プロセスを再起動すると、この問題は常に修正されます。

応答時間のグラフを見ると、外部サービスが実際にはしばらく遅かったが、その後ノードの一部が回復した場合でも、そのノードがダウンしていると見なされるようです。遅い応答時間は単に私たちの側のバグの機能である可能性があるため、これは現時点では単なる推測です.

以下にコードの抜粋を追加しました。リクエストごとに新しい交換オブジェクトを作成するため、データ キャッシュに問題はないと確信しています。 

public void doSomething() {
    HttpExchange httpExchange = new HttpExchange();
    httpExchange.setURL("SOME_URL");
    httpExchange.setMethod("GET");
    httpExchange.setEventListener(listener);
    httpExchange.setTimeout(this.timeout);
    this.client.send(httpExchange);
}

Jetty HttpClient で同様の問題を見た人はいますか? Jetty Http Client がこのように動作する原因となる既知のエッジ ケースはありますか?
Jetty の内部に、オーバーロードされたバグがあるかどうかを確認する必要がある共有オブジェクトはありますか?

4

1 に答える 1

0

参考までに、私はサイトでバグ追跡を開始しました。最終的に、再現性、回避策、および作業中の修正のための一連の適切な手順が用意されました。

ただし、当面の修正については、「現在、.onExpire() イベント ハンドラで HttpExchange.cancel() を呼び出してこの問題を回避しています。この同じ修正をテストできますか?」--Wade Simmons がバグ追跡を参照

于 2012-08-28T14:01:59.287 に答える