サーブレットを介してJMSキューからメッセージを受信または使用すると、パフォーマンスに問題があります。
サーブレットに対する単純なリクエストでは、QueueSessionオブジェクトのcloseメソッド(JMSリソースを閉じる)の実行に10秒かかります。 サーブレットを複数回連続して使用すると、closeメソッドに20〜30秒かかります。 並列実行(一度に10リクエスト)は、queueConnection.close()に対して6〜7分かかります。 同期ブロックでは、queueConnection.close()の実行に20〜30秒の値が戻ってきます。Glassfishは、JMSキューの接続/セッションリソースを遅延で閉じます。 JMS接続プーリングの仕組み
私はサーブレットスレッドがプールから同じQueueConnectionを受け取っていると感じました。
サーブレットがプールから無料の接続リソースを取得するようにしてはいけませんか?
JMS接続ファクトリのプール設定を行うことができます。 初期および最小プールサイズ、最大プールサイズ、プールサイズ変更数、アイドルタイムアウト、最大待機時間。 私はプーリングのいくつかの設定を試しましたが、私は良い結果を得ていません。
私はOpenMQ接続プールから取得した接続をプールするために自分自身でプーリングを実装する必要があると思います。
私はキュー内に40,000を超えるメッセージを持ちます。メッセージはメッセージセレクタを使用してパラメータ化されていますから、close-Method(JMS Ressourcesを解放する)の遅延の理由はありますか? パフォーマンスを向上させるためにファイルベースの永続性からjdbcベースの永続性に切り替えることは重要ですか?
以下の答えで、OpenMQのUMSコンポーネントを使用することをお勧めしました。 UMSは便利ですが、メッセージセレクタを使用する必要があり、UMSではサポートされていないと思います。
ありがとうございます!
コーディング:あなたは、私が最も強くあなたを助言する...あなたのデザインで何か問題があるかもしれないサーブレットにメッセージを消費する必要があると感じた場合
...
public void init(ServletConfig config) throws ServletException {
...
messageReceiver = new MessageReceiver();
...
}
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException
{
...
...
synchronized (this)
{
message = messageReceiver.receive(KEY, keyValue);
}
...
...
}
私は単純なアプリケーションが必要なので、MessageListener(Message Driven Bean)を使用しないでください。 http:// localhost:port/myServlet?mykey = abcdef –
OpenMQのUMSコンポーネント(GlassfishのJMS実装)は、あなたが必要とするすべてのものである可能性があります(JMSプロパティ/ messageSelector)その場合 - http://mq.java.net/4.3-content/ums/umsMain.htmlを調べてください。 – fvu
メッセージセレクタを使用する必要がありますが、これはUMSではサポートされていません。 –