目次


WebSphere Application Server V6によるポイズン・メッセージの処理方法

Comments

概要

IBM WebSphere Application Server バージョン 6.x は、Java ™ Message Service (JMS) 仕様に基づく非同期メッセージングをサポートします。デフォルト・メッセージング・プロバイダーまたは IBM WebSphere MQ を使用して、宛先 (メッセージ・キューまたはトピック) で listen するメッセージ駆動型 Bean (Message-Driven Bean, MDB) を作成できます。メッセージが宛先に到着すると MDB が呼び出され、その onMessage() メソッドが呼び出されます。「ポイズン・メッセージ」が MDB に送信された場合、アプリケーションはそのメッセージを拒否できます。このような状況で、メッセージはどのように処理され、アプリケーション・サーバーはどのように動作するのでしょうか。

この記事は、読者が JMS の基本的な知識を持っていることを前提としています。

ポイズン・メッセージとは何か

ポイズン・メッセージとは、受信した MDB アプリケーションが処理できないメッセージのことです。メッセージが壊れているか、予期しないフォーマットか、または MDB のビジネス・ロジックで取り扱うことができない情報が含まれているような場合が考えられます。例えば、書籍の注文を処理する MDB があるとします。存在しない書籍の注文を MDB が受け取ると、その注文メッセージはポイズン・メッセージとみなされる場合があります。

「ポイズン・メッセージ」が MDB に送信されると、Bean は以下の 3 つのいずれかの 1 つを実行できます。

  • メッセージを元の宛先にロールバックします。 これは、MDB がトランザクション内で実行されていれば可能で、メッセージが失われないことが保証されます。メッセージを元の宛先に返すと、MDB はメッセージを再び処理します。これは、データベースが使用不可などの一時的な問題があるために、アプリケーションがメッセージを処理できない場合に役立ちます。メッセージをロールバックするためには、MDB は Bean と関連付けられたメッセージ駆動型コンテキストで setRollbackOnly() メソッドを呼び出します。

  • メッセージを別の宛先に移動します。 これはポイズン・メッセージが失われないので、MDB がトランザクション内で実行されていない場合に特に役立ちます。システム管理者は後でメッセージを検査し、メッセージを処理できなかった理由を調べ、再処理できるように MDB がモニターしている宛先に送り返すことができます。

  • 何もしないでメッセージを破棄します。 つまり、メッセージは永遠に失われます。

ポイズン・メッセージを受信したかどうか、およびどのように取り扱う必要があるかを決定するのは、MDB アプリケーションの責任です。JMS プロバイダーまたはアプリケーション・サーバーは、メッセージが壊れているかどうか、処理できないかどうかを決定することはできません。

ポイズン・メッセージのロールバック

トランザクション内で実行されている MDB は、処理できないメッセージをロールバックできます。この状況で、アプリケーション・サーバーは何を実行するのでしょうか。答えは、どのような JMS プロバイダーが使用されているかによって決まります。

デフォルト・メッセージング・プロバイダーの使用

デフォルト・メッセージング・プロバイダーを使用するように構成された MDB は、サービス統合バスがホストするキューやトピック・スペースをモニターします。メッセージがキューに到着するか、トピックでパブリッシュされると、メッセージはMDB に送信されます。MDB がメッセージをロールバックするときのアプリケーション・サーバーの動作は、以下の 3 つのプロパティー値によって決まります。

  • JMS メッセージ・プロパティー DeliveryCount は、JMS メッセージがアプリケーションに送信された回数を示します。このプロパティーは、MDB が送信後にメッセージを拒否した場合にインクリメントされます。

  • JMS 宛先プロパティー 最大デリバリー失敗数 (Maximum failed deliveries) は、宛先のメッセージがこの宛先に対して定義された例外宛先に移動される前に、MDB に送信される回数を指定します。このプロパティーのデフォルト値は 5 です。つまり、メッセージが 5 回ロールバックされると、アプリケーション・サーバーはメッセージを別の場所に移動します。このプロパティーは、WebSphere Application Server 管理コンソール (図 1) の宛先の構成パネルで変更できます。

    図 1 TestDestination の 最大デリバリー失敗数 プロパティー
    図 1  TestDestination の 最大デリバリー失敗数 プロパティー
    図 1 TestDestination の 最大デリバリー失敗数 プロパティー
  • JMS 宛先プロパティー 例外宛先 (Exception destination) は、最大デリバリー失敗数 プロパティーで指定した回数だけロールバックされたポイズン・メッセージを、アプリケーション・サーバーがどのように処理するかを指定します。例外宛先 プロパティーは、3 つの値のうちのいずれか 1 つを持つことができます。

    • システム (System): メッセージをシステム例外宛先 _SYSTEM.Exception.Destination.<messaging engine name>に送付します。
    • なし(None): メッセージを元の宛先に残します。
    • 指定(Specify): メッセージをユーザー指定の例外宛先に移動します。

    このプロパティーのデフォルト値は「システム」です。このため、最大デリバリー失敗数の回数より多くロールバックされたメッセージは、宛先をホストするメッセージング・エンジンに定義されたシステム例外宛先に移動されます。最大デリバリー失敗数 プロパティーと同様に、例外宛先 プロパティーは WebSphere 管理コンソール (図2) の宛先の構成パネルで変更できます。

    図 2 TestDestination の 例外宛先 は「システム」に設定されます
    図 2  TestDestination の 例外宛先 は「システム」に設定されます
    図 2 TestDestination の 例外宛先 は「システム」に設定されます

メッセージング・エンジン・カスタム・プロパティー sib.processor.blockedRetryTimeout は、例外宛先 プロパティーが「なし」に設定されている場合にのみ、ポイズン・メッセージを MDB に再送信する前にアプリケーション・サーバーが待つ時間を指定します。このプロパティーは WebSphere Application Server バージョン 6.0.2.x および 6.1 でのみ使用可能で、そのデフォルト値はバージョンによって異なります。

  • バージョン 6.0.2.x では、このプロパティーのデフォルト値は 0 ミリ秒で、ロールバックされたメッセージは直ちに MDB に再送信されます。
  • バージョン 6.1 では、デフォルト値は 5000 ミリ秒で、これは 5 秒に相当します。したがって、バージョン 6.1 でロールバックされるメッセージは MDB に再送信される前に元の宛先のままで 5 秒間待ちます。

メッセージがロールバックされると、その DeliveryCount がインクリメントされ、メッセージが当初送信された宛先の 最大デリバリー失敗数 の値と比較されます。

DeliveryCount が 最大デリバリー失敗数 より小さい場合、メッセージは再処理できるように宛先に返されます。

DeliveryCount が 最大デリバリー失敗数以上であれば、メッセージング・エンジンは指定された 例外宛先 にメッセージを移動するか、例外宛先 が 「なし」に設定されていれば、再び送信する前に sib.processor.blockedRetryTimeout により指定された時間だけ待ちます。この動作を図 3 に示します。

図 3 デフォルト・メッセージング・プロバイダーによるポイズン・メッセージの処理方法
図 3  デフォルト・メッセージング・プロバイダーによるポイズン・メッセージの処理方法
図 3 デフォルト・メッセージング・プロバイダーによるポイズン・メッセージの処理方法

デフォルトの動作

デフォルトでは、最大デリバリー失敗数 プロパティーの値は 5 で、例外宛先 は 「システム」 に設定されます。これらのデフォルト値を使用した場合、ポイズン・メッセージが宛先に到着してから MDB に送信されるとどのようになるでしょうか。

  1. MDB はメッセージを処理できないので、メッセージをロールバックし、DeliveryCount が 1 に増やされます。DeliveryCount は宛先の 最大デリバリー失敗数 より小さいので、メッセージング・エンジンはメッセージを宛先に返します。

  2. MDB はメッセージを再び受信しますが、依然処理できないので、以前と同じようにロールバックを実行します。メッセージの DeliveryCount は 2 に設定されます。この値は宛先の 最大デリバリー失敗数 より小さいので、メッセージング・エンジンは元の宛先にメッセージを返します。

  3. このパターンが、メッセージが 5 回ロールバックされるまで繰り返されます。

  4. ここで、DeliveryCount の値が宛先の 最大デリバリー失敗数 の値と同じになります。メッセージング・エンジンは、メッセージを元の宛先に返さずに _SYSTEM.Exception.Destination.<messaging engine name>として指定された宛先の例外宛先に移動します。

分散プラットフォーム上での WebSphere MQ の使用

メッセージ・リスナー・サービスは、WebSphere MQ によってホストされる JMS 宛先を listen する MDB によって使用されます。MDB は、キュー・マネージャー上でホストされる個別のキューまたはトピックをモニターするために構成されたリスナー・ポートにバインドされます。メッセージがキューに入れられるか、特定のトピックでパブリッシュされると、メッセージはリスナー・ポートによって検出され、MDB に送信されます。MDB がメッセージをロールバックする場合、アプリケーション・サーバーの動作は以下の 4 つのプロパティーによって決まります。

  • リスナー・ポート・プロパティー 最大再試行数 (Maximum retries) は、リスナー・ポートを停止する前にメッセージ・リスナー・サービスが MDB にメッセージを送信する回数を指定します。このプロパティーのデフォルト値は 0 です。つまり、MDB がメッセージを初めてロールバックするときに、それと関連付けられたリスナー・ポートがシャットダウンします。最大再試行数 プロパティーは、図 4 に示す WebSphere Application Server 管理コンソールのリスナー・ポート構成パネルで変更できます。

    図 4 リスナー・ポート TestMDBListener の 最大再試行数
    図 4  リスナー・ポート TestMDBListener の 最大再試行数
    図 4 リスナー・ポート TestMDBListener の 最大再試行数
  • JMS メッセージ・プロパティー DeliveryCount は、JMS メッセージがアプリケーションに送信された回数を示します。このプロパティーは、MDB が送信後にメッセージを拒否するとインクリメントされます。

  • WebSphere MQ キュー・プロパティー バックアウトしきい値 (BOTHRESH) は、メッセージが別の場所に移動される前にキューに入れることができる最大回数を指定します。このプロパティーのデフォルト値は 0 です。つまり、メッセージ・リスナー・サービスは、MDB によってロールバックされたメッセージを再びキューに入れることはありません。バックアウトしきい値の値は、WebSphere MQ コマンド行ユーティリティー runmqsc または WebSphere MQエクスプローラー (図 5) のキューのプロパティー・パネルを使用して設定できます。

    図 5 キュー testの バックアウトしきい値 プロパティー
    図 5  キュー testの バックアウトしきい値 プロパティー
    図 5 キュー testの バックアウトしきい値 プロパティー
  • WebSphere MQ キュー・プロパティー バックアウト・リキュー・キュー(BOQNAME) は、メッセージが バックアウトしきい値プロパティーに指定した回数だけキューにロールバックされたときにメッセージを移動するキューの場所です。バックアウト・リキュー・キューにデフォルト値はありません。つまり、アプリケーション・サーバーは、バックアウトしきい値を超えたメッセージを SYSTEM.DEAD.LETTER.QUEUE に移動します。バックアウト・リキュー・キュー プロパティーは、WebSphere MQ ユーティリティー runmqsc または WebSphere MQエクスプローラーを使用して設定できます。キューのプロパティー・ パネルを図 6 に示します。

    図 6 キュー testの バックアウト・リキュー・キュー プロパティーを SYSTEM.DEAD.LETTER.QUEUE に設定
    図 6  キュー testの バックアウト・リキュー・キュー プロパティーを SYSTEM.DEAD.LETTER.QUEUE に設定
    図 6 キュー testの バックアウト・リキュー・キュー プロパティーを SYSTEM.DEAD.LETTER.QUEUE に設定

ポイズン・メッセージがロールバックされるときにメッセージ・リスナー・サービスが最初に実行することは、メッセージの DeliveryCount をインクリメントし、送信されたキューに返すことです。

メッセージ・リスナー・サービスは DeliveryCountとリスナー・ポートの 最大再試行数 プロパティーを比較します。DeliveryCountが 最大再試行数 以上であれば、リスナー・ポートが停止します。それ以外の場合、リスナーは実行を続けます。

リスナー・ポートが次にメッセージを検出した場合、メッセージ・リスナー・サービスは DeliveryCount とキューの バックアウトしきい値を比較します。DeliveryCount が バックアウトしきい値より小さければ、メッセージはキューに残って再処理できる状態になります。ただし、DeliveryCount が バックアウトしきい値 と等しい場合は、メッセージ・リスナー・サービスはメッセージを バックアウト・リキュー・キュー に移動します。バックアウト・リキュー・キュー が定義されていない場合は、メッセージは SYSTEM.DEAD.LETTER.QUEUE に移動されます。

この動作を図 7 に示します。

図 7 WebSphere MQ JMS プロバイダーを使用するときの、アプリケーション・サーバーによるポイズン・メッセージの処理
図 7  WebSphere MQ JMS プロバイダーを使用するときの、アプリケーション・サーバーによるポイズン・メッセージの処理
図 7 WebSphere MQ JMS プロバイダーを使用するときの、アプリケーション・サーバーによるポイズン・メッセージの処理

デフォルト動作

デフォルトでは、最大再試行数 プロパティーの値は 0 で、バックアウトしきい値 プロパティーと バックアウト・リキュー・キュー プロパティーのいずれも値を持ちません。すると、WebSphere MQ によってホストされている JMS 宛先を listen している MDB にポイズン・メッセージが送信された場合、デフォルト動作はどのようになるでしょうか。

  1. MDB はメッセージをロールバックし、メッセージの DeliveryCount が 1 に増やされます。メッセージ・リスナー・サービスは、DeliveryCount とリスナー・ポートの 最大再試行数 プロパティーの値 (0) を比較します。DeliveryCount が 最大再試行数 より大きければ、リスナー・ポートは停止します。

  2. リスナー・ポートが再始動すると、ポイズン・メッセージを再検出してメッセージの DeliveryCount とキューの バックアウトしきい値 プロパティーの値を比較します。このプロパティーは値を持たないので、メッセージは MDB に送信されます。MDB が依然としてメッセージを処理できないと、メッセージがキューにロールバックされてDeliveryCount が 2 にインクリメントされます。メッセージ・リスナー・サービスはもう一度 DeliveryCount と 最大再試行数 プロパティーを比較し、リスナー・ポートは再びシャットダウンされます。

  3. リスナー・ポートが次に再始動されると、メッセージを検出し、サイクル全体が繰り返されます。

この動作の結果として、ポイズン・メッセージによりキューのその他のメッセージの処理がブロックされる状況になる場合があります。

メッセージがロールバックされると、キューの元の位置に戻されます。リスナー・ポートは常にキューの先頭からメッセージ処理を開始するので、キューの最初のメッセージがポイズン・メッセージであれば、リスナー・ポートはそのメッセージを検出して MDB に送信します。メッセージを処理できないので、MDB はメッセージをロールバックし、メッセージは再びキューの先頭に戻ります。リスナー・ポートがシャットダウンされます。リスナー・ポートが再始動すると、ポイズン・メッセージを再検出して MDB に再送信します。MDB がメッセージをロールバックし、リスナー・ポートは再停止します。

デフォルト動作の変更

おわかりのように、デフォルトの動作はポイズン・メッセージがシステム管理者によってキューから削除されるまで継続します。

デフォルト動作を行わないようにするには、リスナー・ポートによってモニターされているキューに バックアウトしきい値 および バックアウト・リキュー・キュー が定義されていることを確認し、バックアウトしきい値 の値がリスナー・ポートの 最大再試行数 より小さいことを確認する必要があります。

例えば、TestMDBListener と呼ばれるリスナー・ポートが定義され、WebSphere MQ キュー testのメッセージをモニターしている場合を考えます。リスナー・ポートの 最大再試行数 プロパティーは 10 に設定し、キューの バックアウトしきい値 は 1 で、バックアウト・リキュー・キュー は SYSTEM.DEAD.LETTER.QUEUE です。

  1. メッセージがキュー testに到着し、リスナー・ポートによって検出されて MDB に送信されます。MDB はこのメッセージを処理できず、ロールバックするとします。メッセージの DeliveryCount は 1 に設定されます。

  2. メッセージ・リスナー・サービスは、この値とリスナー・ポートの 最大再試行数 プロパティーを比較します。このプロパティーの値は 10 で DeliveryCount より大きいので、リスナーは実行を続けます。

  3. リスナー・ポートが次にメッセージを検出すると、メッセージ・リスナー・サービスはメッセージの DeliveryCount をチェックして値が 1 であることを認識します。キュー testの バックアウトしきい値 をチェックすると、その値は 1 です。したがって、メッセージ・リスナー・サービスはメッセージをバックアウトすることを決定します。

  4. メッセージ・リスナー・サービスは、キューの バックアウト・リキュー・キュー プロパティーを照会します。これは SYSTEM.DEAD.LETTER.QUEUE に設定されているので、メッセージ・リスナー・サービスはキュー testからメッセージを削除してこのキューに入れます。

  5. メッセージ・リスナー・サービスはキュー testのモニタリングに戻り、その他のメッセージが到着するまで待ちます。

ポイズン・メッセージに対する 最大セッション数 プロパティーの影響

リスナー・ポートの「最大セッション数」プロパティーは、リスナーが同時に処理できるメッセージの最大数を定義します。このプロパティーの値が 10 で、リスナー・ポートによってモニターされているキューにメッセージが 10 個あれば、10 個のメッセージがすべて同時に処理されます。これは、メッセージの 1 つを処理できず、ロールバックされる場合に影響があります。

おわかりのように、ポイズン・メッセージが MDB によってロールバックされると、アプリケーション・サーバーのデフォルト動作は、送信されたキューにメッセージを返してリスナー・ポートを停止することです。ただし、最大セッション数 プロパティーが 1 より大きい値に設定されていると、リスナー・ポートを停止する前にメッセージを再処理できます。

多くの状況ではこれによって問題が生じることはなく、メッセージが再びロールバックされるまでにリスナー・ポートが停止され、メッセージを再び送信しようとはしません。ところが、MDB がトランザクション作業と非トランザクション作業を実行する場合、非トランザクション作業が再び実行される可能性があります。これが発生しないようにするには、バックアウトしきい値 プロパティーを 1 に設定する必要があります。これによりアプリケーション・サーバーは、リスナー・ポートが停止する前にメッセージを再送信するのではなく、バックアウト・リキュー・キュー に移動します。

ポイズン・メッセージの処理に対する 最大メッセージ数 プロパティーの影響

「最大メッセージ数」というリスナー・ポートに別のプロパティーがありますが、このプロパティーもポイズン・メッセージが検出されたときのアプリケーション・サーバーの動作に影響を与えます。このプロパティーは 1 つのトランザクション内で MDB によって処理されるメッセージの数を指定します。最大メッセージ数 のデフォルト値は 1 で、各メッセージは独自のトランザクションで処理されます。

この値が増やされると、MDB はメッセージのバッチを同時に処理します。バッチ内の 1 つのメッセージが処理されずにロールバックされると、そのバッチ内のすべてのメッセージがロールバックされます。

例えば、最大メッセージ数 が 10 に設定されているとします。リスナー・ポートが始動すると、10 個のメッセージが MDB に送付され、MDB はそのメッセージを順に処理します。最初の 5 個のメッセージが正常に処理され、6 番目のメッセージが正常に処理されなかったとします。MDB がこのメッセージをロールバックすると、アプリケーション・サーバーは処理されていない 4 個のメッセージとともに、正常に処理された 5 個のメッセージをロールバックします。

リスナー・ポートによってモニターされているキューの バックアウトしきい値 が 1 に設定されていると、10 個のメッセージがすべて バックアウト・リキュー・キュー に移動されてしまいます。

これは、最大メッセージ数 の値の増加を検討するときに認識して、慎重に考慮すべき事柄です。

リスナー・ポートおよび別名キュー

リスナー・ポートは、WebSphere MQ ローカルおよびリモート・キューのメッセージを探すように構成するだけでなく、別名キューをモニターするようにセットアップすることもできます。そのようにアプリケーション・サーバーをセットアップするには、別名キューが指しているローカルまたはリモート・キューに バックアウトしきい値 プロパティーと バックアウト・リキュー・キュー プロパティーが設定され、アプリケーション・サーバーが、ローカルまたはリモート・キューのこれらの属性の値を照会するアクセス権を持っていることが重要です。

アプリケーション・サーバーがこれらの属性の値を判断できない場合、バックアウトしきい値 の値として 20 を使用し、バックアウト・リキュー・キュー プロパティーの設定は無指定のままになります。つまり、別名キューをモニターしているリスナー・ポートによって検出されたポイズン・メッセージは、SYSTEM.DEAD.LETTER.QUEUE に移動される前に 20 回ロールバックされます。

WebSphere MQ セキュリティーに関する考慮事項

よくある質問は次のとおりです。 「メッセージをバックアウトするには、WebSphere Application Server システムにどのような WebSphere MQ 許可が必要ですか。」

WebSphere Application Server がメッセージをバックアウトするには、アプリケーション・サーバーが実行されているユーザー ID が バックアウト・リキュー・キュー で以下のアクセス権を持つ必要があります。

  • Inquire
  • Pass All Context
  • Put
  • Set All Context

アプリケーション・サーバーがこれらのアクセス権を持っていないと、メッセージ・リスナー・サービスがポイズン・メッセージをバックアウトするときに、以下のエラー・メッセージが生成されます。

WMSG0018E: Error on JMSConnection for MDB <MDB Name> , JMSDestination <Destination name> : javax.jms.JMSException: MQJMS1081: Message requeue failed

z/OS 上の WebSphere MQ プロバイダーの使用

z/OS 上で WebSphere MQ JMS プロバイダーを使用するときのポイズン・メッセージの処理方法は上と同じですが、1 つだけわずかな違いがあります。

z/OS 上での WebSphere MQ は、メッセージのメモリー内コピーを使用します。メッセージが初めてリスナー・ポートによって検出されると、WebSphere MQ はそのコピーをアプリケーション・サーバーに渡す前にメモリーに格納します。メッセージが正常に処理されると、メモリー内コピーが削除され、実際のメッセージがストレージから削除されます。

MDB がメッセージをロールバックすると、WebSphere MQ はメモリー内コピーの DeliveryCount をインクリメントします。アプリケーション・サーバーはコピーのこのプロパティーの値をチェックし、実際のメッセージを バックアウト・リキュー・キュー に移動するかどうかおよびリスナー・ポートを停止するかどうかを決定します。メモリー内コピーの DeliveryCount の値が バックアウトしきい値 の値より大きいと、実際のメッセージは バックアウト・リキュー・キュー に移動されてメモリー内コピーが削除されます。

これは、メッセージがバックアウトされる前に WebSphere MQ システムが停止した場合に影響があります。

TestMDBListener2 という別のリスナー・ポートを定義したとします。リスナー・ポートの 最大再試行数 プロパティーは 10 に設定されています。これは、WebSphere MQ キュー test2 をモニターしてメッセージを探すために構成されます。このキューは z/OS 上で実行されている WebSphere MQ キュー・マネージャーによってホストされ、バックアウトしきい値 プロパティーは 5 に設定されます。

  1. メッセージがキューに到着し、TestMDBListener2 によって検出されます。メッセージのコピーが作成され、MDB に送信されます。ところが MDB はメッセージを処理できないので、メッセージをロールバックします。メッセージのメモリー内コピーの DeliveryCount がインクリメントされて 1 になります。

  2. リスナー・ポートはメッセージを再検出し、もう一度 MDB に送信します。MDB は 2 回目のロールバックを行います。メッセージのメモリー内コピーの DeliveryCount は 2 になります。

  3. z/OS キュー・マネージャーがこの時点でシャットダウンされたとします。アプリケーション・サーバーはメッセージのメモリー内コピーのみを処理していたので、キューにストアされた実際のメッセージの DeliveryCount は依然 0 に設定されたままです。キュー・マネージャーが再始動されると、リスナー・ポートがメッセージを再検出します。メッセージの新しいメモリー内コピーが作成され、その DeliveryCount は 0 です。メッセージが MDB によってロールバックされると、コピーの DeliveryCount の値は 1 にインクリメントされます。

  4. この動作は、MDB がメッセージを 5 回ロールバックするまで続きます。このとき、アプリケーション・サーバーはメッセージのメモリー内コピーの DeliveryCount がキューの バックアウトしきい値 と等しいことを認識して、実際のメッセージを バックアウト・リキュー・キュー プロパティーによって指定されたキューに移動します。

このシナリオでは、ポイズン・メッセージはバックアウトされる前に 7 回実際に処理されます。これはキューに定義された バックアウトしきい値 より大きい値です。

この動作は理想的ではありません。

この動作を実行しないようにするには、ロールバックが行われるときに、メモリー内コピーだけでなくストレージ内の実際のメッセージの DeliveryCount も更新するように z/OS 上の WebSphere MQ を構成する必要があります。つまり、DeliveryCount 値は永続化されるので、キュー・マネージャーが再始動してもそのままです。それには、MDB によってモニターされているキューの HardenGetBackout (HNDBKTCNT) プロパティーを YES に設定する必要があります。

まとめ

この記事では、ポイズン・メッセージとは何かを説明し、ポイズン・メッセージを受信したときに JMS アプリケーションが実行できることについて説明しました。デフォルト・メッセージング・プロバイダーと WebSphere MQ JMS プロバイダーは、MDB がポイズン・メッセージをロールバックする状況をどのように取り扱うか、デフォルトの動作をどのように変更できるか、WebSphere MQ JMS プロバイダーを使用するときに一部のリスナー・ポート・プロパティーがアプリケーション・サーバーの動作にどのように影響するかについても学習しました。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=342764
ArticleTitle=WebSphere Application Server V6によるポイズン・メッセージの処理方法
publish-date=03052008