3

キープアライブがないと仮定すると、サーブレットコンテナがスタンドアロンサーバーとして機能している場合、応答全体がクライアント (Web ブラウザーなど) に送信されるまで、サーブレットのスレッドは解放されないと想定します。これは正しい仮定ですか？

しかし、サーブレットが Nginx のようなリバース プロキシの背後にある場合はどうなるでしょうか? 応答が Nginx に配信されるとスレッドは解放されますか、それとも応答が最終的なクライアント (ブラウザーなど) に送信されるまで保持されますか?

更新：これをもう少し明確にしてみましょう。

応答がサーブレットから nginx のようなプロキシに送信されるまでにかかる時間はわずか数ミリ秒 (たとえば 2 ミリ秒) です。ただし、nginx からブラウザーに最終的な応答が送信されるまでに、さらに 80 ミリ秒 (またはその程度) かかる場合があります。サーブレットは、応答が nginx に送信されるとスレッド/ストリームを解放しますか、それとも、応答がブラウザーに送信されるまで (つまり、80 ミリ秒全体) サーブレットはスレッド/ストリームを保持しますか?

4

3 に答える 3

2

質問:応答全体がクライアント (Web ブラウザーなど) に送信されるまで、サーブレットのスレッドは解放されないと思います。これは正しい仮定ですか？

回答：いいえ、違います。サーブレットコンテナはコンテンツをソケットに書き込んで返すだけです。write() メソッドからの戻りによって、応答がクライアントに到達したことが保証されるわけではありません。

質問:応答が Nginx に配信されるとスレッドは解放されますか、それとも応答が最終的なクライアント (ブラウザーなど) に送信されるまで保持されますか?

回答: Nginx が背後にある場合、サーブレット コンテナーのクライアントは Nginx です。実際のリモート クライアントは認識されません。そのため、応答が Nginx に書き込まれると、スレッドは解放されます。

于 2013-04-02T05:01:49.007 に答える
1

サーバー コンテナーがクライアントに応答を送信できないと、コンテナーによって処理される例外がトリガーされます。最後に try catch (close() を使用) によって出力ストリームまたはライターへの書き込みを囲むことができますが、その必要はありません。プールへのスレッドの戻りを含め、コンテナーが管理します。よろしくS

于 2013-04-01T21:26:54.227 に答える
1

サーブレットはネットワークを認識しません。仕様によると、2 つのオブジェクトが処理されます: Request と Response が入力されます (HTTP の場合、これは HTTPRequest と HTTPResponse を意味します)。リクエスト オブジェクト内のリクエスト データを処理し、レスポンス オブジェクト内のバッファに書き込みます。そのコンテンツがサーブレットによってコミットされると、コンテナーは (フィルターを使用して) 何らかの後処理を行い、それをクライアントに送り返します。

リクエスト処理メソッドの呼び出しが完了すると、サーブレット スレッドは自然にプールに戻ります (メソッドがさらに作業を行う必要がある場合、ペイロードがクライアントに送り返された後に発生する可能性があります)。

サーブレットはネットワークを認識せず、単一の要求のみを考慮するため、http 接続の状態 (キープアライブまたはクローズ) はサーブレットの有効期間とは無関係であることに注意してください。複数のサーブレットが、1 つの接続でパイプライン化されたさまざまな要求を処理する場合があります。関連する問題については、この質問を参照してください。

于 2013-04-01T22:13:50.843 に答える