3

私はこれについて困惑しているので、HttpClient の開発はちょっとした芸術であるため、誰かがそれに遭遇した場合に備えて質問すると思いました。

私が直面している問題は次のとおりです。アプリケーションが Apache HttpClient Java ライブラリを使用して、同じ企業ネットワーク内のサーバーと通信しています。ほとんどの場合は問題なく動作しますが、不完全な応答が原因で例外が大量に発生することがあります。これらはすべて終了タグの最後の 3 文字が欠落しているため、クライアントのパーサーがエラーを出します。これはおそらく5〜10分間続き、その後消えます.

この問題をローカルで再現することはできませんでした。応答がサーバーによって完全に書き込まれていることを確認しました。クライアントは PostMethod の getResponseBodyAsStream() メソッドを使用して応答コンテンツを取得していますが、1 回しか呼び出されていません。おそらく、応答がバッファリングされるまれなケースで null になるまで、このメソッドの呼び出しをループする必要がありますか?

ご意見をお待ちしております。

編集: サーバーは content-length ヘッダーを書き込んで正しくフラッシュしています。クライアントでは、データは次の文字列に読み込まれます。

//method is a PostMethod, client is a HttpClient
client.executeMethod(hostconfig, method); 

InputStream is = method.getResponseBodyAsStream();
String response = null;

try {
    ByteArrayOutputStream bos = new ByteArrayOutputStream();    
    byte[] buf = new byte[1024];
    int len;

    while ((len = is.read(buf)) > 0) {
        bos.write(buf, 0, len);
    }

    response = new String(bos.toByteArray(), "UTF-8");

} ... // closing try block
4

2 に答える 2

1

サーバーからの content-length ヘッダーは正しく設定されていますか? Commons-HttpClient がそれらを尊重するかどうかは 100% わかりませんが、簡単に可能です。getResponseBodyAsStream を繰り返し呼び出す必要がある理由が思いつきません。

ストリームを読み取るためのコードが誤った仮定をしている可能性もあります。おそらく、ストリーム全体を実際に正しく読み取っていることを確認するために、データの読み取り方法のスニペットを確認できますか? いくつかの一般的なコーディングの間違いにより、バッファリングされた量までしか読み取れない可能性があります (これにより、一見ランダムなエラーが発生します)。

それ以外は、言うのは難しいです... Commons HttpClient を定期的に使用しており、同様の症状はありません。

于 2009-07-31T20:34:10.890 に答える
1

私もこの問題に直面してきました。この問題は、URL を localhost から public に変更した後にのみ発生しました。

私はいくつかの解決策を見つけました...

私が見つけた最初の「解決策」は、読み取りプロセスを開始する前に Thread.sleep(1000) を実行することでした。これにより、読み取りを試みる前にバッファーがいっぱいになると思います。( read() はデータが利用可能になるまでブロックすると述べているため、これが意味をなさないことはわかっていますが、残念ながら read メソッドは予想より早く終了したと考えることがあります)。これは醜いパッチのようなものなので、探し続けます...

2 番目のオプションであり、最適なオプションは、BufferedReader のメソッド readLine() を使用することです。このメソッドは、読み取りプロセスを正しく実装します。私は readLine のソース コードを読んでいませんが、そこに問題の解決策を見つけることができると思います。

ご挨拶。

于 2009-10-30T00:58:29.403 に答える