このセクションでは、さまざまな高度なトピックについて説明します。これらのトピックは、特別な状況または十分に経験のあるユーザにのみ適用されます。 このセクションは、次のトピックに分かれています。
JMS仕様は、多くの一般的なアプリケーション要件を満たす、3種類の確認モードを定義します。 しかし、JMSでは、メッセージが個々に確認される訳ではありません。 CLIENT_ACKNOWLEDGEを使用すると、acknowledge
メソッドがどのメッセージで呼び出されたかに関係なく、コンシューマにより受信されたすべてのメッセージが確認されます。
jBroker MQでは、JMQSessionのINDIVIDUAL_ACKNOWLEDGE
フラグを使用して、メッセージを個々に確認することができます。 この例は、個々のメッセージを削除(確認)できる、キューおよび永続的サブスクライバの管理者アプリケーションを作成する方法を示します。
JMS仕様では、メッセージの期限、つまりJMSプロバイダによりメッセージが破棄されるまでの時間を指定できます。 しかし、標準のAPIでは、メッセージの開始時刻を指定することはできません。 信頼性を損なわずにメッセージの配信を送らせる機能は、メッセージアプリケーションの作成時に重要な機能です。 この例では、jBroker MQ JMS_jbmq_Delay
メッセージプロパティの使用方法を示します。
jBroker MQでは、JMS_jbmq_Compress
ブールプロパティを使用したメッセージの自動圧縮機能がサポートされています。 JMS_jbmq_Compress
がtrueに設定されている場合、メッセージは、サーバに転送される前に自動的に圧縮され、メッセージコンシューマに送られる前に自動的に解凍されます。 圧縮は、すべてのメッセージタイプ(バイト、マップ、オブジェクト、ストリーム、SOAP、テキスト、XMLおよびファイル)に対してサポートされています。 メッセージ圧縮を使用すると、ネットワーク接続が遅い場合、またはメッセージが大きい場合、パフォーマンスが向上します。
JMSには、コンシューマのコールバックとメッセージ配信のシリアル化について厳しい規則があります。 セッションに複数のコンシューマがある場合、一度に呼び出されるonMessageメソッドは1つだけです。 これは、onMessageをスレッドセーフにしなければならないということを気にしなくて済むので、アプリケーション開発者にとっては、大きな利点になります。
パフォーマンス上の理由で、高度なアプリケーションではメッセージを同時に消費することがあります。 このため、connection consumerと呼ばれる個別のオプションコンストラクトがJMSで定義されています。 このサンプルプログラムでは、ServerSessionPoolの作成方法、およびサブスクライブメッセージの同時処理を接続コンシューマに設定する方法を示します。
例外リスナは、JMSクライアントアプリケーションが非同期に発生するエラーを検出できるという強力な機能です。 たとえば、jBroker MQサーバへの接続が切断されるか、メッセージがメッセージリスナに配信できなかった場合、例外リスナに通知されます。 この例では、例外リスナのさまざまな使用を示します。
アプリケーションによっては、処理中にjBroker MQサーバを実行して、メッセージが集中するクライアントからの配信や消費の速度を向上する、またはシステムプロセス数を減らすことがあります。 この例では、JMQMessageService APIを使用して、処理中にjBroker MQを実行する方法を示します。
この例は、サーブレット内からjBroker MQ宛先にアクセスする方法を示します。 サーブレットは、他のJMSクライアントアプリケーションと同じプログラミングモデルを使用しますが、WARとして配備されるので、さらに構成する必要があります。 サーブレットの初期化は、jmqrunクライアントアプリケーションの実行側とほぼ同じ環境を設定する必要があります。
この例は、JMSAdmin
管理可能オブジェクトを使用して、jBroker MQサーバからランタイムプロパティを取得する方法を示します。 jBroker MQプロパティは、処理されるメッセージ数などのさまざまなカウンタと言えます。 これらのプロパティの監視は、jBroker MQサーバのヘルスステータスにアクセスするときに使用されます。