14.3. クライアント側 JMS パフォーマンスの最適化
概要
2 つの主要な設定がクライアントの JMS パフォーマンスに影響します。プーリングと同期受信です。
プーリング
クライアント側で、CXF はメッセージごとに新しい JMS セッションおよび JMS プロデューサーを作成します。これは、session および producer オブジェクトがスレッドセーフであるためです。プロデューサーの作成には、サーバーと通信する必要があるため、特に時間がかかります。
接続ファクトリーのプールは、接続、セッション、およびプロデューサーをキャッシュすることでパフォーマンスを向上します。
ActiveMQ の場合は、プーリングの設定が簡単です。以下に例を示します。
import org.apache.activemq.ActiveMQConnectionFactory;
import org.apache.activemq.pool.PooledConnectionFactory;
ConnectionFactory cf = new ActiveMQConnectionFactory("tcp://localhost:61616");
PooledConnectionFactory pcf = new PooledConnectionFactory();
//Set expiry timeout because the default (0) prevents reconnection on failure
pcf.setExpiryTimeout(5000);
pcf.setConnectionFactory(cf);
JMSConfiguration jmsConfig = new JMSConfiguration();
jmsConfig.setConnectionFactory(pdf);プーリングの詳細は、Red Hat JBoss Fuse トランザクションガイド の付録 AJMS シングルおよびマルチリソーストランザクションのパフォーマンスの最適化を参照してください。
同期受信の回避
要求/応答交換の場合、JMS トランスポートは要求を送信してから応答を待ちます。可能な場合は、JMS MessageListener を使用してリクエスト/リプライメッセージングが非同期に実装されます。
ただし、エンドポイント間でキューを共有する必要がある場合は、CXF は同期 Consumer.receive() メソッドを使用する必要があります。このシナリオでは、MessageListener がメッセージセレクターを使用してメッセージをフィルターする必要があります。メッセージセレクターは事前に認識される必要があるため、MessageListener は一度だけ開かれます。
メッセージセレクターを事前に知ることができない 2 つのケースは避ける必要があります。
JMSMessageIDがJMSCorrelationIDとして使用される場合JMS プロパティーが
useConduitIdSelectorおよびconduitSelectorPrefixが JMS トランスポートに設定されていない場合、クライアントはJMSCorrelationIdを設定しません。これにより、サーバーはJMSCorrelationIdとしてリクエストメッセージのJMSMessageIdを使用します。JMSMessageIDは事前に認識できないため、クライアントは同期Consumer.receive()メソッドを使用する必要があります。IBM JMS エンドポイントで
Consumer.receive()メソッドを使用する必要があることに注意してください (デフォルト)。ユーザーはリクエストメッセージに
JMStypeを設定し、カスタムJMSCorrelationIDを設定します。ここでも、カスタムの
JMSCorrelationIDは事前に認識できないため、クライアントは同期Consumer.receive()メソッドを使用する必要があります。
したがって、一般的なルールは、同期受信の使用を必要とする設定の使用を避けることです。