アプリケーションサーバー用にTomcatを実行しています。
PDF を生成してブラウザに返すサーブレットがあります。次に、一時 PDF ファイルを削除します。
問題は、削除のタイミングに問題があったことです。私たちのチームの誰かが、ファイルを削除する前に 20 秒待つべきだと判断したので、彼らは Thread.sleep(20000) を使用します。
興味深いのは、出力ストリームを閉じて 20 秒待ってから、ファイルを削除して doGet() を終了することです。
私の質問は次のとおりです。出力ストリームは応答で閉じられるため、待機する前にすぐにブラウザーに戻ります。追加の 20 秒の待機にパフォーマンス上の懸念はありますか? たとえば、ネットワーク接続などを拘束しますか?
いいえ、私はそのようなものをアプリケーションに入れ、かなりの時間実行しています。出力ストリームのみが閉じられているため、ユーザーの現在の要求と通信できなくなりますが、doGet が存在しなかったため、サーブレットのオブジェクトは、スレッド タイムアウトが終了するまで破棄されません。
削除と待機はバックグラウンド タスクのようにメモリ内でのみ発生するため、おそらくネットワーク帯域幅に関する問題はありません。そのネットワークの帯域幅に影響を与えるのは、応答を送信するのにかかる時間だけであり、応答が速いためです。その後、後で作業を終了してください。
ただし、ファイルを削除する代わりに destroy() メソッドを使用することをお勧めします。
File.createTempFile() を使用して一時ファイルを作成し (既にこれを試していて、何らかの理由で実行できない場合を除きます)、いつ削除するかを Java に決定させることをお勧めします。サーブレットで Thread.sleep() を使用することにより、本質的にサーブレット インスタンスを保持しています。ServletContainers は後続のリクエスト用にサーブレットのプールを作成し、20 秒間存続するサーブレットはプール サイズを増やし、サーブレットは次のリクエストで使用できなくなるため、コンテナには後続のリクエスト用に新しいインスタンスを作成する以外に選択肢がありません。 .
ネットワークまたは帯域幅に関連する問題がない場合があります。ただし、説明している方法でサーブレットを保持することは、災害のレシピです。