WebSphere Application Server V7 および V8 での WebSphere MQ メッセージング・プロバイダー・アクティベーション・スペックによるメッセージ処理

この記事ではまず、WebSphere Application Server での WebSphere MQ メッセージング・プロバイダー・アクティベーション・スペックと、このアクティベーション・スペックが WebSphere MQ キュー・マネージャーに接続し、メッセージ宛先をモニタリングするために使用するメカニズムについて概説します。その後、WebSphere Application Server がメッセージ駆動型 Bean に処理対象として適切なメッセージを送達する仕組みを解説します。この記事は、システムのチューニングを担当する WebSphere Application Server の管理者および開発者、そして WebSphere Application Server と WebSphere MQ との相互作用を理解したいと思っている WebSphere MQ 管理者を対象としています。

Paul Titheridge, Service Specialist, WebSphere MQ Level 3 Support team, IBM

Photo of Paul TitheridgePaul Titheridge は 2003 年から、英国 IBM Hursley Lab のWebSphere MQ Level 3 Support チームで働いています。彼の専門は、WebSphere MQ と WebSphere Application Server 間の相互接続に関する問題を解決することです。



2012年 6月 11日

はじめに

IBM WebSphere Application Server V7 および V8 では、JMS (Java Message Service) 仕様に基づく非同期メッセージングをサポートしています。WebSphere MQ メッセージング・プロバイダーを使用する場合、WebSphere MQ の宛先 (メッセージ・キューまたはトピック) をリッスンするメッセージ駆動型 Bean を作成できます。メッセージが宛先に到着するとメッセージ駆動型 Bean の onMessage() メソッドが呼び出され、メッセージが処理されます。

WebSphere Application Server V7 および V8 では、WebSphere MQ メッセージング・プロバイダーがアクティベーション・スペックを使用して、WebSphere MQ キュー・マネージャーがホストする宛先をモニタリングできるようになっています。この記事では、アクティベーション・スペックが分散型プラットフォームの WebSphere MQ に接続する仕組みを紹介します。メッセージを探して宛先をモニタリングするために使用されるメカニズム、そして適切なメッセージが検出された後にメッセージ駆動型 Bean が呼び出される仕組みを学んでください。この記事では、読者が JMS および WebSphere MQ の基本知識を持っていることを前提とします。

アクティベーション・スペック

大まかに言うと、J2C アクティベーション・スペックとは、JMS プロバイダーへの接続方法に関する情報と、その JMS プロバイダー上でモニタリングされるメッセージの宛先の詳細が保管される管理対象オブジェクトです。メッセージ駆動型 Bean を使用するアプリケーションをデプロイするときには、メッセージ駆動型 Bean が使用するアクティベーション・スペックを指定する必要があります。アクティベーション・スペックは起動すると、JMS プロバイダーに接続して JMS 宛先を開き、その宛先をモニタリングしてメッセージを探します。

以下の図 1 と図 2 に、WebSphere Application Server管理コンソールの「Activation specification (アクティベーション・スペック)」パネルを使って定義した WebSphere MQ アクティベーション・スペックの例を示します。この例のアクティベーション・スペックは、起動すると pault という名前のローカル WebSphere MQ キュー・マネージャーにバインディング・モードで接続し、宛先 jms/TestQueue を開きます。そして、この宛先のモニタリングを開始して、メッセージを待ち受けます。

図 1. キュー・マネージャーの名前とトランスポート・タイプの指定
キュー・マネージャーの名前とトランスポート・タイプの指定
図 2. アクティベーション・スペックでモニタリングする JMS 宛先の指定
アクティベーション・スペックでモニタリングする JMS 宛先の指定

アクティベーション・スペックは、メッセージ・セレクターを使用するように構成することもできます。メッセージ・セレクターによって、選択基準にマッチしたメッセージだけを、アクティベーション・スペックからメッセージ駆動型 Bean に渡すことができます。上記の図 2 ではメッセージ・セレクターが指定されていないので、このアクティベーション・スペックは、宛先に到着したすべてのメッセージを処理対象として扱うことになります。

アクティベーション・スペックは処理対象のメッセージを見つけると、WebSphere Application Server 内でメッセージを処理するための作業をスケジュールします。作業を実行するには、メッセージのそれぞれに JMS サーバー・セッションが必要です。この条件を満たしていれば、複数のメッセージを同時に処理できます。

各アクティベーション・スペックにはサーバー・セッション・プールが関連付けられ、プールのサイズによって、アクティベーション・スペックが同時に処理できるメッセージの数が決まります。サーバー・セッション・プールのデフォルト・サイズは 10 です。これは、1 つのアクティベーション・スペックが最大 10 個のメッセージを同時に処理できることを意味します。サーバー・セッション・プールのサイズを変更するには、アクティベーション・スペックの拡張プロパティー「Maximum server sessions (最大サーバー・セッション)」を変更します (図 3 を参照)。

図 3. 同時に処理可能なメッセージ数の指定
同時に処理可能なメッセージ数の指定

メッセージの検出

WebSphere MQ キュー・マネージャーでホストされているJMS 宛先のメッセージを検出するためにアクティベーション・スペックが使用するメカニズムは、使用している WebSphere MQ メッセージング・プロバイダー・モードによって異なります。これから、これらのモードについて説明します。

WebSphere MQ メッセージング・プロバイダー標準モード

アクティベーション・スペックが WebSphere MQ V7 キュー・マネージャーに接続していて、アクティベーション・スペックの「Provider version (プロバイダー・バージョン)」プロパティーが未指定 (デフォルト値) または 7 に設定されている場合は、WebSphere MQ メッセージング・プロバイダー標準モードが使用されます。この動作モードのアクティベーション・スペックは、WebSphere MQ V7 のさまざまな機能を使用してキュー・マネージャーに接続し、メッセージを取得します。このモードで起動したアクティベーション・スペックは、以下の操作を行います。

  1. 使用するように設定されている WebSphere MQ キュー・マネージャーに接続します。
  2. アクティベーション・スペックがキュー宛先を使用するように構成されている場合は、WebSphere MQ API の MQOPEN 呼び出しを使用してキューを開きます。
  3. アクティベーション・スペックがトピック宛先を使用するように構成されている場合は、WebSphere MQ API の MQSUB 呼び出しを実行して該当するトピックをサブスクライブします。
  4. キューを開いた後、またはトピックをサブスクライブした後、アクティベーション・スペックは WebSphere MQ API の MQCB 呼び出しによってコールバックを登録します。コールバックは、以下の WebSphere MQ GetMessageOption を使用してセットアップされます。
    • MQGMO_BROWSE_FIRST
    • MQGMO_UNMARKED_BROWSE_MSG
    • MQGMO_MARK_BROWSE_CO_OP
  5. コールバックが登録されると、アクティベーション・スペックは WebSphere MQ MQCTL API 呼び出しを実行します。これにより、アクティベーション・スペックがメッセージを受信できる状態であることがキュー・マネージャーに通知されます。

適切なメッセージが、アクティベーション・スペックのモニタリング対象のキューに到着した時点、またはアクティベーション・スペックが登録しているトピックにパブリッシュされた時点で、キュー・マネージャーはそのメッセージにマークを付け、他のアクティベーション・スペックがそのメッセージを見えないようにします。その後、セットアップされたコールバックによって、キュー・マネージャーがアクティベーション・スペックにメッセージの詳細を渡します。

WebSphere MQ メッセージング・プロバイダー・マイグレーション・モード

アクティベーション・スペックが WebSphere MQ キュー・マネージャーに接続するためのもう 1 つの方法は、WebSphere MQ メッセージング・プロバイダー・マイグレーション・モードを使用することです。このモードは、以下の条件のいずれかに該当する場合に使用されます。

  • アクティベーション・スペックが、WebSphere MQ V6 キュー・マネージャーに接続するように構成されている。
  • アクティベーション・スペックが WebSphere MQ V7 キュー・マネージャーに接続するように構成されていて、その「Provider Version (プロバイダー・バージョン)」プロパティーが 6 に設定されている。
  • アクティベーション・スペックが CLIENT トランスポートを使用して WebSphere MQ V7 キュー・マネージャーに接続するように構成されていて、共有会話 (SHARECNV) プロパティーが 0 に設定された WebSphere MQ チャネルを使用している。

マイグレーション・モードで起動した場合、アクティベーション・スペックは以下の操作を行います。

  1. 使用するように設定されている WebSphere MQ キュー・マネージャーに接続します。
  2. アクティベーション・スペックがキュー宛先をモニタリングするように構成されている場合は、MQOPEN API 呼び出しを実行してキューを開きます。
  3. アクティベーション・スペックがトピック宛先を使用するように構成されている場合は、以下の操作を行います。
    • トピックのサブスクリプションを開きます。
    • アクティベーション・スペックのブローカー・プロパティー「Broker connection consumer subscription queue (ブローカー接続コンシューマー・サブスクリプション・キュー)」および「Broker durable subscriber connection consumer queue (ブローカー永続サブスクライバーの接続コンシューマー・キュー)」をチェックして、ブローカーがこのアクティベーション・スペックのメッセージをどの WebSphere MQ キューにパブリッシュするかを確認します。
    • WebSphere MQ API の MQOPEN を呼び出して、該当するサブスクリプション・キューを開きます。
  4. キュー・マネージャーのキューが開いた後は、アクティベーション・スペックが MQGET API 呼び出しを何度か実行して、キューをブラウズし、メッセージを探します。アクティベーション・スペックは WebSphere MQ GetMessageOption の MQGMO_BROWSE_FIRST と MQGMO_BROWSE_NEXT を組み合わせて実行し、キューを上から下までスキャンします。

メッセージの処理

アクティベーション・スペックは (WebSphere MQ V7 キュー・マネージャーからコールバックによってメッセージに関する情報が渡されたため、あるいはアクティベーション・スペックが適切なメッセージをブラウズしたために) 宛先でメッセージを検出すると、以下の操作を行います。

  1. メッセージを表すメッセージ参照を作成します。
  2. アクティベーション・スペックのサーバー・セッション・プールからサーバー・セッションを取得します。
  3. サーバー・セッションにメッセージ参照をロードします。
  4. WebSphere Application Server のワーク・マネージャーで作業をスケジュールします。

以上の操作を完了すると、アクティベーション・スペックは別のメッセージを再び探し始めます。

サーバー・セッションの取得

前述のように、アクティベーション・スペックはデフォルトで最大 10 個のメッセージを同時に処理できます。ですが、アクティベーション・スペックがメッセージを処理しようとしたときに、10 のサーバー・セッションのすべてがメッセージを処理中だったとしたらどうなるでしょうか。この場合、アクティベーション・スペックはサーバー・セッションが解放されるまで新しい処理をブロックします。サーバー・セッションが使用可能になると同時に、アクティベーション・スペックはメッセージ参照をロードして、サーバー・セッションが再び実行できるように新しい作業をスケジュールします。

作業のスケジューリング

アクティベーション・スペックは、サーバー・セッションにメッセージ参照をロードすると、メッセージを処理するための作業をスケジュールします。作業がどのように処理されるのかと言うと、ワーク・マネージャーが以下の操作を行います。

  1. WebSphere Application Server の WebSphere MQ メッセージング・プロバイダーのリソース・アダプター・スレッド・プールからスレッドを取得します。このスレッド・プールの名前は WMQJCAResourceAdapter です。
  2. 取得したスレッドで作業を実行します。

WebSphere Application Server のワーク・マネージャーは、スケジュールされた作業を実行します。作業が開始された後の流れは以下のとおりです。

  1. ローカルまたはグローバル (XA) トランザクションのいずれかを開始します。どちらのトランザクションを開始するかは、メッセージ駆動型 Bean に XA トランザクションが必要かどうかによって決まります (これは、メッセージ駆動型 Bean のデプロイメント記述子に指定されています)。
  2. 初めて使用されるサーバー・セッションの場合には、以下の操作が行われます。
    • WebSphere MQ との新規接続を作成します。
    • MQOPEN API 呼び出しを実行して、メッセージがあるキューを開きます。
  3. MQGET API 呼び出しを実行して、WebSphere MQ からメッセージを取得します。
  4. メッセージ駆動型 Bean の onMessage() メソッドを実行します。
  5. onMessage() が完了すると、サーバー・セッションはローカルまたはグローバル・トランザクションを完了させてから終了します。

パフォーマンスを向上させるために、メッセージが処理されて作業が完了した後も、サーバー・セッションが使用するキュー・マネージャーとの接続はオープン状態で維持されます。したがって、メッセージを処理するためにサーバー・セッションが次に使用されるときに、WebSphere MQ に再接続してメッセージが入れられたキューを再び開く必要はありません。デフォルトでは、アクティベーション・スペックに関連付けられたサーバー・セッションは 30 分間オープン状態で維持され、その間に使用されなければ切断されます。このタイムアウトが発生するまでの時間は、アクティベーション・スペックの拡張プロパティー「Server session pool timeout (サーバー・セッション・プールのタイムアウト)」の値を変更することで延長できます (図 4 を参照)。

負荷の小さいシステムでは、作業がスケジュールされてからワーク・マネージャーがその作業を開始するまで、ほんのミリ数秒しかかからないこともありますが、ビジーなシステムでは、作業が実際に開始されるまでにかなりの遅延が生じる可能性があります。この遅延には以下の 2 つの理由が考えられます。

  • WMQJCAResourceAdapter スレッド・プールに、作業を実行可能なフリー・スレッドがない。
  • ワーク・マネージャーはスレッド・プールからスレッドを取得できたが、WebSphere Application Server がビジー状態であったため、作業を開始できない。

ワーク・マネージャーは、作業がスケジュールされた時間と作業の開始時間を記録して、アクティベーション・スペックが作業をスケジュールしてからの経過時間を確認します。アクティベーション・スペックはデフォルトで、作業がスケジュールされてから 10 秒以内に開始されることを期待します。ワーク・マネージャーが作業を開始する前に 10 秒が経過したした場合には、WorkRejected 例外がアクティベーション・スペックに返され、WebSphere Application Server の SystemErr.log に以下のような例外が記録されます。

Exception in thread "WMQJCAResourceAdapter : 1" java.lang.RuntimeException:
javax.resource.spi.work.WorkRejectedException: Work timed out (id=4), error code: 1
:   :   :   :   :   :   :   :   :   :   :   :   :   :   :   :   :   :   :   :   :   :  
Caused by: javax.resource.spi.work.WorkRejectedException: Work timed out
(id=4), error code: 1

このような例外が発生した時点で、キュー・マネージャーはメッセージ参照のメッセージを「マーク解除」しているはずです。したがって、メッセージは再処理できるようになっています。この 10 秒の時間制限を変更するには、アクティベーション・スペックの「Advanced properties (拡張プロパティー)」パネルにある「Start timeout (開始までのタイムアウト)」を使用してください (図 4 を参照)。

図 4. サーバー・セッション・タイムアウトおよび作業開始待機時間の変更
サーバー・セッション・タイムアウトおよび作業開始待機時間の変更

既に説明したように、WMQJCAResourceAdapter スレッド・プールに十分なスレッドがなければ、作業を開始するまでに遅延が生じます。そこで浮かんでくる明らかな疑問は、「スレッド・プールの適切なサイズ」です。アクティベーション・スペックでは、1 つのアプリケーション・サーバーにつき 1 つのスレッド・プールを使用してサーバー・セッションを実行します。アクティベーション・スペックごとに「Maximum server sessions (最大サーバー・セッション)」という拡張プロパティーがあり、同時に実行できるサーバー・セッションの最大数を定義します。メッセージを処理するためには、それぞれのサーバー・セッションが使用されるため、このプロパティーは必然的に、メッセージ駆動型 Bean がこのアクティベーション・スペックを使用して同時に処理できるメッセージ数を意味します。したがって、WMQJCAResourceAdapter スレッド・プールの適切なサイズを判断するには、WebSphere Application Server 上の WebSphere MQ メッセージング・プロバイダーの各アクティベーション・スペックに指定された「Maximum server sessions (最大サーバー・セッション)」プロパティーの値を合計すれば良いということになります。例えば、25 個のアクティベーション・スペックが定義されていて、それぞれの「Maximum server sessions (最大サーバー・セッション)」プロパティーが 3 に設定されているとしたら、最大 75 個のサーバー・セッションを同時に実行されることになります。これらのサーバー・セッションのそれぞれが、WMQJCAResourceAdapter スレッド・プールのスレッドを使用するので、このスレッド・プールの最大サイズは 75 個に設定する必要があります。このスレッド・プールのサイズを変更するには、図 5 に示す WebSphere管理コンソールの「WMQJCAResourceAdapter」スレッド・プール・パネルを使用します。

図 5. WebSphere Application Server に定義されたすべてのアクティベーション・スペックが使用できる最大スレッド数の変更
WebSphere Application Server に定義されたすべてのアクティベーション・スペックが使用できる最大スレッド数の変更

WebSphere Application Server の SystemOut.log ファイルに WorkRejected エラーが記録されるようになった場合、真っ先に確認しなければならないのは、WMQJCAResourceAdapter スレッド・プールに、アクティベーション・スペックに必要なすべてのサーバー・セッションを処理するだけの大きさがあるかどうかです。スレッド・プールが適正なサイズであれば、ワーク・マネージャーが指定された時間内に作業要求を開始できないことがエラーの原因ということになります。その場合には、アクティベーション・スペックの拡張プロパティー「Start Timeout (開始までのタイムアウト)」の値を増やすか、WebSphere Application Server システムの負荷を減らす方法を調べてください。

WebSphere MQ メッセージング・プロバイダー標準モードを使用する

前述のとおり、メッセージが検出されてから、メッセージ駆動型 Bean で処理されるまでに遅延が発生する原因には以下の 3 つあります。

  • アクティベーション・スペックに関連付けられているサーバー・セッションがすべて使用されている
  • WMQJCAResourceAdapter スレッド・プール内のすべてのスレッドがメッセージの処理に使用されている
  • 作業がスケジュールされてから、ワーク・マネージャーが実際にその作業を開始するまでに時間がかかっている

アクティベーション・スペックが WebSphere MQ メッセージング・プロバイダー標準モードで実行中の場合、キュー・マネージャーはメッセージにマークを付けてから、メッセージの詳細をアクティベーション・スペックに渡します。メッセージにマークを付けるということは、同じ WebSphere Application Server で実行されているか、別のサーバーで実行されているかに関わらず、他のアクティベーション・スペック (または WebSphere Application Server リスナー・ポート) にはメッセージが見えなくなるということです。これにより、サーバー・セッションがメッセージを処理する前に、別のメッセージ駆動型 Bean がメッセージを取得するという事態がなくなります。

メッセージにマークが付けられる時間はデフォルトで 5 秒間です。この時間を変更するには、WebSphere MQ キュー・マネージャーのメッセージ・マークの参照間隔 (MARKINT) プロパティーを変更します。

WebSphere MQ が処理対象のメッセージの詳細をアクティベーション・スペックに渡すと、5 秒タイマーが起動します。この 5 秒以内に、以下の操作が行われなければなりません。

  1. アクティベーション・スペックがサーバー・セッション・プールからサーバー・セッションを取得する。
  2. 処理対象のメッセージの詳細をサーバー・セッションにロードする。
  3. 作業をスケジュールする。
  4. ワーク・マネージャーが作業要求を開始する。

サーバー・セッションを取得する際、または WMQJCAResourceAdapter スレッド・プールからスレッドを取得する際に遅延が生じた場合、あるいはシステムがビジー状態でワーク・マネージャーが作業をスケジュールするのに時間がかかった場合には、WebSphere MQ がメッセージの詳細を渡してから、実際にメッセージが使用されるまでの時間が 5 秒を超える可能性があります。その場合には、どうなるのでしょうか。

メッセージがキューに入れられている時間が 5 秒を超えると、キュー・マネージャーがそのメッセージのマークを解除し、別のアクティベーション・スペックまたはリスナー・ポートが自由にメッセージを取得できるようになります。この場合、前にこのメッセージの詳細がロードされていたサーバー・セッションがメッセージを取得しようとすると、宛先にメッセージがなくなっていることがわかり、以下のメッセージが WebSphere Application Server の SystemOut.log に書き込まれます。

CWSJY0003W: JMSCC0108: WebSphere classes for JMS attempted to get 
a message for delivery to an message listener that had previously been 
marked using browse-with-mark, but the message was not there.

このメッセージを受け取った場合には、以下の 3 つの選択肢があります。

  • WebSphere MQ キュー・マネージャーのメッセージ・マークの参照間隔 (MARKINT) プロパティーの値を増やすします。これによって、アクティベーション・スペックがメッセージを取得するための時間を延ばします。複数のアプリケーションに同じ宛先をモニタリングさせていて、メッセージを素早く処理する必要がある場合、この方法の採用については慎重に考えてください。メッセージにマークが付けられている時間を長くすると、他のアプリケーションがその期間、メッセージを取得できなくなるからです。
  • サーバー・セッションの待機、または WMQJCAResourceAdapter スレッド・プールからのスレッドの待機によるブロックが発生しないようWebSphere Application Serverを調整すること。それには、サーバー・セッション・プールとスレッド・プールのサイズの両方を増やします。このように変更すると、デフォルトのメッセージ参照マーク期間内により多くのメッセージを同時に処理できるようになるため、WebSphere Application Server 内で使用されるリソースが増える結果となります。
  • 何もしない。この選択肢は推奨されません。何もしなければ、アクティベーション・スペックが別のアプリケーションによって既に取得されて処理されたメッセージを取得しようとして、時間とリソースを無駄に使うことになるからです。

まとめ

この記事では、アクティベーション・スペックがキュー・マネージャーに接続する方法、そしてJMS 宛先をモニタリングして処理対象として適切なメッセージを探すために使用するメカニズムを含め、アクティベーション・スペックが WebSphere MQ キュー・マネージャーからメッセージを取得するために使用するメカニズムを説明しました。また、適切なメッセージを見つけた後に、WebSphere Application Server がメッセージの処理をスケジュールする方法についても説明しました。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=819808
ArticleTitle=WebSphere Application Server V7 および V8 での WebSphere MQ メッセージング・プロバイダー・アクティベーション・スペックによるメッセージ処理
publish-date=06112012