2

サーブレット 3.0 では、「リクエスト」スレッド (または「メイン」スレッド) が長時間実行される処理を他のスレッドに委譲し、それ自体を解放してより多くのリクエストを受け取ることができます。同意した。つまり、マルチスレッドを活用することで（リクエストの）スケーラビリティを実現しています。

ただし、これには、私の「サーブレット コンテナ JVM」がそのような処理に対応している必要があります。「サーブレット コンテナ JVM」がエントリ ポイントにすぎず、リクエストを処理するロジックが他の JVM の別の場所にある多層アーキテクチャがあるとしたらどうなるでしょうか (以降、この記事では「サービス JVM」と呼びます)。

受信した「リクエスト」(または少なくともリクエストの関連属性) を JMS キューにポストし、「サービス JVM」のプールから「リクエスト」を取得して処理させたい場合はどうすればよいですか? この Service JVM にも「応答」(JSON など) を送信する責任を委任したほうがよいのではないでしょうか?

「AsyncContext」をサーブレット コンテナ JVM の外で意味のある形で渡すことができるとは思いません。では、分散サービス (JVM) によって実行されるように、要求処理と応答送信を実際に委任するにはどうすればよいでしょうか?

コード/疑似コードに関して、私の質問は次のとおりです。

@WebServlet(urlPatterns = "/AsyncServlet", asyncSupported=true)
public class AsyncServlet extends HttpServlet {

    protected void doGet(HttpServletRequest request,
            HttpServletResponse response)
        throws ServletException, IOException {

        AsyncContext asyncCtx = request.startAsync();
        // Put the asyncCtx in a JMS queue so as to be picked by another 
        // service JVM that can really service this request.
        // return back to receiving requests and dont worry abt sending a response
        // The service JVM will take care of sending the appropriate response
        // as it has the data necessary for the response.
    }
}

1 つのオプションは、(サーブレット コンテナー JVM 内の) ワーカー スレッドにサービス JVM からの応答を待機させることです。サービス JVM が実際の処理を行った後、結果を (メッセージまたはその他の方法で) それぞれのワーカー スレッドに伝達し、ワーカー スレッドに GET 応答を送信させることができます。

これは非常に複雑に見えるので、これよりも優れた代替手段があるかどうかを知りたいです（確かにあるはずです！）。

4

1 に答える 1

1
  1. コンテキストを非同期として設定
  2. シングルトン Bean 内にコンテキストを保存する
  3. JMS リクエストを送信する
  4. JMS リクエストの処理
  5. JMS 返信を送信する
  6. シングルトン Bean からの応答のコンテキストを取得する
  7. クライアントに返信を送る

クリーンアップ用のタイマーを設定したい場合があり、jms を非同期の一方向 ejb 呼び出しに置き換えることができます

于 2013-03-27T21:24:40.717 に答える