問題タブ [gzipinputstream]

大量の圧縮テキスト ファイル (1000 以上のファイル、100 MB から 1.5 GB のサイズ) でTextIO.Read変換を使用すると、次のエラーが発生することがあります。

同じ ZipException をオンラインで検索すると、次の応答のみが返されます。

アプリケーションが deploy ディレクトリに完全にコピーされる前に、ホット デプロイヤがアプリケーションをデプロイしようとすると、Zip ファイル エラーがよく発生します。ファイルのコピーに数秒かかる場合、これはかなり一般的です。解決策は、ファイルをアプリケーション サーバーと同じディスク パーティション上の一時ディレクトリにコピーしてから、そのファイルを deploy ディレクトリに移動することです。

他の誰かが同様の例外に遭遇しましたか? またはとにかく、この問題を解決できますか?

gzip で圧縮された大きなテキスト ファイルを処理する必要があります。

このコードは、ループ内で長い計算を行わない場合に機能します (そうする必要があります)。しかし、各行に数ミリ秒のスリープを追加するだけで、最終的にプログラムがクラッシュし、java.util.zip.ZipException が発生します。例外のメッセージは毎回異なります (「無効なリテラル/長さコード」、「無効なブロック タイプ」、「無効な格納ブロック長」)。
そのため、ストリームを十分にすばやく読み取っていないと、ストリームが破損しているようです。

問題なくファイルを解凍できます。Apache Commons Compress の GzipCompressorInputStream も試してみましたが、同じ結果が得られました。
ここで何が問題で、どうすれば解決できますか?

更新 1

私はこれを除外したと思っていましたが、さらにテストを行ったところ、問題はインターネットからのストリーミング ファイルに限定されていることがわかりました。

完全な例:

興味深いことに、行番号を出力すると、プログラムがクラッシュするのは常に同じ 4 ～ 5 行のうちの 1 行であることがわかりました。

update 2

実際のファイルを含む完全な例を次に示します。

このファイルでは、90000 行付近でクラッシュが発生しています。

タイムアウトの問題を除外するために試しconnection.setReadTimeout(0)ましたが、効果はありませんでした。

おそらくネットワークの問題です。しかし、ブラウザでファイルをダウンロードできるので、それを処理する方法が必要です。

更新 3

Apache HttpClient を使って接続してみました。

現在、次の例外が発生していますが、これはおそらくより役立つでしょう。

繰り返しますが、ブラウザでファイルをダウンロードして問題なく解凍できるため、問題を処理する方法が必要です。

更新 このエラーは GZIP ストリームに関連していることがわかりました。それらを削除し、オブジェクト ストリームでラップされた GZIP ではなくオブジェクト ストリームを使用するだけで、問題は解決されます。例外はありません。誰かがそれを助けることができれば、それは素晴らしいことです。

また、GZIP を使用しているときに、エラーが非常にランダムになることにも気付きました。たとえば、ソケットを介して送信していたオブジェクト内のデータに大きく依存しているように見えました。オブジェクト データを変更すると、問題が解決する場合があります。たとえば、名前、姓、電話番号などの文字列値を含むユーザー オブジェクトがありました。それらがすべて設定されている場合、以下の問題が発生していましたが、それらをすべてクリアして空の文字列値にすると、以下の例外は発生しません。正直に言うととても奇妙です

GZIP ストリーム経由でオブジェクトを送信するクライアント/サーバー ソケットがあります。これは過去に問題なく機能しました。ただし、サーバーからクライアントに特定のデータを送信するときに、接続がリセットされます。

クライアントがサーバーに接続してリクエストを送信すると、サーバーはこれに応答してデータを送り返します。クライアント側で接続リセットの例外が表示されるため、エラーはサーバーからのものだと思います。

ここに例外のスニペットがあります

すべてのクライアント/サーバー通信に同じソケット実装が使用され、テスト環境ではすべて正常に動作するため、これは非常に奇妙な問題です。また、例外が発生する前に同じコードが正常に使用され、起動時にクライアントがアプリケーションをロードするときにサーバーからデータが収集されます。

上記の情報から、渡される特定のデータに問題がある可能性があると思われますが、クライアントとサーバーの両方に接続のリセット以外の例外はありません。

デバッグ中に netstat ( netstat -anp ) を見ると、アクションが成功するとソケットが「CLOSE_WAIT」の状態になることがわかりますが、失敗した場合はソケットがすべて一緒に消えているように見えますが、どの状態にもありません。また、接続リセット例外が発生しない成功した場合でも、接続が終了すると多くの RST が発生することにも注意してください。私の TCP の知識はあまりよくありませんが、クリーンな接続は RST ではなく FIN で終わると思っていたでしょうか?

これがコードの例です

クライアント：

サーバーはこの時点ですでに「リクエスト」を読み取っているため、これはリクエストされたデータをクライアントに返す部分にすぎません。サーバ：

デバッグ ログの場合、サーバーは例外なく最後まで実行されます (そのため、"< run" がログに書き込まれます)。ただし、クライアントエラー

ois = 新しい ObjectInputStream(gZipIn);

注目に値するもう1つの項目は、例外が発生するライブシステムがLinux（Centos）を実行していることです。Windowsで例外を複製できず、Linux Mintでも発生しません。これが原因だとは思いませんが、言及する必要があると思いました。

ここで問題の原因がわからないので、助けていただければ幸いです。

単一の統合ファイルにシーケンスしようとしているレコードを含む gzip ファイルが多数あります。CPU パワーは制約ではありません。

必要に応じて GZipInputStreams から読み取るスレッドをスピンアップしたいと考えています。任意の時点で各ファイルから読み取られる量は変動し、予測できません。この問題を解決する最も明白な方法は、バッキング バッファーがロー ウォーターマークを下回った場合に GZipInputStream から読み取るためにタスクが送信されるスレッド プールを用意することです。

データは 1 つのスレッドからのみ消費されると想定されていた可能性があるため、異なるスレッドから単一の GZipInputStream を読み取ると、メモリ バリアの問題が明らかになる可能性があることを懸念しています。

明確にするために、複数のスレッドが同じ GZipInputStream から同時に読み取ることを示唆しているわけではありませんが、ストリームが 1 つのスレッドから読み取られ、すぐに別のスレッドから読み取られた場合、同期モニターがないために一部のデータに一貫性がなくなる可能性があります。 .

一部の Web サイトの圧縮に問題があります。次のコードは問題なく動作するはずですが、EOFException. すべての主要なブラウザーでサイトを読み込むことができ、gzip で curl を使用しても問題ありません。

これは出力になります：

また、gzip エンコーディングに問題がある Web サイトはこれだけではありません。私も問題を抱えています

• mgtv.com
• yxdown.com
• weather.com.cn
• ebrun.com

私は何か間違ったことをしていますか？

私のシステムは Win7 x64、Java 8 Update 102 です。

前もって感謝します！

編集:自分でストリームを読み取って例外を飲み込むことができましたが、例外が発生した時点で、bufferSizeバイトが失われ、ドキュメントが破損または不完全になる可能性があります。この問題を解決する方法はありますか ( bufferSizeを 1 に設定する以外)?

編集 2:例外が発生するまでバイトを取得するための回避策として、次のようにストリームを読み取ることができます。

しかし、ここでの問題は、bufferSizeをどのように選択するかです。たとえば、1000 に設定すると、現在の 1000 バイトの最後を読み取るときに例外が発生するなどの時点で、直前に正しく読み取られた 999 バイトがすべて失われます。完全性の完璧な値は 1 ですが、それは非常に遅いです。

では、パフォーマンスを落とさずにすべての正しい読み取り可能なデータを取得するにはどうすればよいでしょうか?