1

1 つのトランザクションで複数のメッセージを使用してパフォーマンスを向上させたいため、onMessage メソッドでメッセージを消費しようとしています。

しかし

Message message = consumer.receive();

null を返します。ブロックもしません。なぜ買う？メッセージを受け取るまでブロックする必要がありますね。 

@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void onMessage(Message message) {

    QueueConnection queueConnection = null;     
    queueConnection = qcf.createQueueConnection();
    queueConnection.start();
    queueSession = queueConnection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
    Queue queue = queueSession.createQueue(sessionConnParams.toString());
    consumer = queueSession.createConsumer(queue);

    // it works in cycle
    System.out.println("before receive");
    Message message = consumer.receive();
    System.out.println("after receive");
    if (message == null) {
       System.out.println("no messages");
       return;
    }

   // process message

   } catch (Exception e) {
     // process exception
   } finally {
     // close objects
   }
}
4

2 に答える 2

1

私の意見では、 onMessage() で別のレシーバーを作成することはお勧めできません。EJB 仕様では、OnMessage メソッドでスレッドを開始することは推奨されていません。

1 つのトランザクションで複数のメッセージを受信して​​も、パフォーマンスは向上しません。パフォーマンスは複数の要因に左右されます

1)onMessageメソッドがメッセージを処理するのにかかった時間。

2) メッセージング プロバイダーがメッセージを配信する速度

3) ネットワーク

4) ハードウェア

パフォーマンスを向上させるために、複数の MDB を並行して実行することを検討できます。また、使用しているメッセージング プロバイダーのパフォーマンス チューニングも確認してください。

これは、 IBMからの便利なリンクの 1 つです。

于 2012-06-24T15:21:34.910 に答える
0

グローバル トランザクションを実行している場合、JMS に自分のやりたいことをさせる可能性は低いと思います。使用する場合

@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)

これにより、アプリケーション サーバーは未指定のトランザクション コンテキストで強制的に実行されます。これが何を意味するかは、使用しているアプリケーション サーバーに完全に依存します。Websphere Application Server を使用している場合は、Bean がトランザクションの外部で実行されるため、メッセージの送受信などの操作が期待どおりに実行されることを意味します。他のアプリケーション サーバーは、これを別の方法で処理する場合があります。ドキュメントを参照してください。とにかく、それをするのはおそらく悪い考えです。アプリケーションサーバーに対して作業しています。

JMS 仕様では、メッセージの配信をバッチ処理するためのメカニズムが定義されています。IBM Websphere MQ は、この先読みhttp://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzaw.doc%2Fjm41130_.htmを呼び出し、複数のメッセージが一度にキューから読み取られ、次々にアプリケーションに配信されます。他の JMS 実装もおそらく同様のものをサポートしています。

ただし、最終的には、アプリケーションでメッセージを常に順番に処理する必要がある場合は、次のメッセージを処理する前に各メッセージをコミットするオーバーヘッドに対処する必要があります。コミットのオーバーヘッドは、ほぼ間違いなく、メッセージを MDB に配信するオーバーヘッドよりもはるかに大きくなります。MDB 内の余分なメッセージを読み取るために何かをハッキングしようとしても、それを回避することはできません。それが問題である場合は、アプリケーションに変更を加えて、メッセージを順不同で処理できるようにする必要があります。

于 2012-08-31T04:27:34.917 に答える