7

HTTP 経由で (大きな) ファイルをデータベースにストリーミングしようとしています。Tomcat と Jersey を Webframework として使用しています。ファイルを自分のリソースに POST すると、ファイルは doPOST メソッドで処理される前に、最初にディスク (temp\MIME*.tmp}) にバッファリングされることに気付きました。

これは、ディスク I/O が 2 倍になり、UX がいくぶん悪くなるため、本当に望ましくない動作です。ブラウザーが既にアップロードを完了している場合、ユーザーはアップロードが完了するまで数分 (もちろんファイル サイズによって異なります) 待つ必要があるためです。 HTTP 応答。

大容量ファイルのアップロードの最適な実装ではないことはわかっていますが (再開機能がないため)、要件も同様です。:/

私の質問は、MULTIPART POST の (ディスク) バッファリングを無効にする方法があるかどうかです。メモリ バッファリングは明らかにコストがかかりすぎますが、とにかくディスク バッファリングの必要性が本当にわかりませんか? (説明してください) YouTube のような大規模なサイトは、この状況をどのように処理しますか? または、ファイルが送信された場合、少なくともユーザーにすぐにフィードバックを提供する機会はありますか? （SQLExceptionのようなものがまだある可能性があるので、悪いはずです）

4

4 に答える 4

4

わかりましたので、何日も読んでさまざまなことを試した後、HTTPServletRequest に出くわしました。@FormDataParam からすべての便利なメソッドが取り除かれるので、最初は試したくありませんでしたが、他に何をすべきかわからなかったので...

それが役に立ったことがわかりました。使用 @Context HTTPServletRequest requestしrequest.getInputStream()ていて、ディスクのバッファリングがまったく得られない場合。

@FormDataParam なしで FormDataContentDisposition に到達する方法を理解する必要があります。

編集：

Ok。MultiPartFormData はおそらく、リクエストの InputStream を解析するためにディスクにバッファリングする必要があります。したがって、バッファリングを防ぎたい場合は、自分で手動で解析する必要があるようです:(

于 2012-05-22T10:10:26.937 に答える
3

メモリがあふれないように、ジャージーがファイルをディスクに書き込んでいると確信しています。受信データで何をする必要があるかを正確に知っているので->データベースにストリーミングする必要があるため、おそらく独自の MessageBodyReader を作成し、ジャージーにそれを使用して受信マルチパートデータを処理させる必要があります。

于 2012-05-16T10:33:31.167 に答える
3

最善の策は、完全に制御して、request.getInputStream (またはテキストを使用している場合は request.getWriter) を取得してストリーミング自体を行う独自のサーブレットを作成することです。ほとんどのフレームワークは、すべてのアップロード、一時ストレージなどを処理することで作業を「楽」にし、多くの場合、ストリーミングなどの操作を困難にします。自分でストリームを取得して、やりたいことをするのはとても簡単です。

于 2012-05-22T15:22:19.970 に答える