はじめに

IBM® WebSphere® Application Server から Java™ Message Service（JMS）プロバイダー（WebSphere MQなど）への接続の作成は、時間とプロセッサー要件の両面で高い負荷がかかります。パフォーマンスを向上させるため、WebSphere Application Serverでは、アプリケーションからJMSプロバイダーへの接続要求時にそのアプリケーションに渡すことができる空き接続をプールに保持しています。この2部構成の記事では、JMS接続プールがWebSphere Application ServerおよびWebSphere MQで機能する方法について説明します。この2部構成記事のパート1では、空き接続プールの使用方法、プールの内容の管理方法、およびプールの各種プロパティーの連携方法について説明しました。パート2では、接続プールのエラー処理、同時接続要求を処理するためのプールの構成、およびWebSphere Application ServerによるWebSphere MQへのJMS接続の管理方法について説明します。

WebSphere Application Serverでは、パフォーマンスを改善するためにJMSプロバイダーへの接続プールが保持されます。JMSアプリケーションがJMSプロバイダーとの通信を要求すると、接続がプールから取り出され、アプリケーションが接続を終了するとプールに返されます。

上に戻る

接続プールのパージ・ポリシー

アプリケーションがJMSプロバイダーへのJMS接続を使用しているときにエラーが検出されると、接続プールのパージ・ポリシーが作用し始めます。接続マネージャーは、以下のいずれかを行うことができます。

• 問題が発生した接続を閉じます。ファクトリーから作成されたその他の接続（他のアプリケーションで使用中の接続とファクトリーの空きプール内にある接続）はそのまま残されます。これはFailingConnectionOnlyパージ・ポリシーと呼ばれるデフォルトの動作です。
• 問題が発生した接続を閉じ、ファクトリーの空きプール内のすべての接続を廃棄し、使用中のすべての接続に失効状態のマークを付けることで、当該の接続を使用しているアプリケーションが次に接続を使用した操作を実行するときにStaleConnectionExceptionを受け取るようにします。この動作を行うには、パージ・ポリシーを「EntirePool」に設定します。

パージ・ポリシーの設定値による動作のいくつかの例を以下に示します。

上に戻る

FailingConnectionOnlyに設定されたパージ・ポリシー

パート1の例を使用して、2つのMDBがアプリケーション・サーバーにデプロイされ、それぞれ異なるリスナー・ポートを使用しているとします。リスナー・ポートはすべて、jms/CF1接続ファクトリーを使用します。10分後、MDBListener1が停止し、このリスナー・ポートが使用していた接続が接続プールに返されます。

MDBListener2がJMS宛先にポーリング中にネットワーク・エラーが発生します。どうなるでしょうか。リスナー・ポートはシャットダウンし、jms/CF1接続ファクトリーのパージ・ポリシーがFailingConnectionOnlyに設定されているため、接続マネージャーはMDBListener2で使用されていた接続のみを廃棄します。空きプール内の接続は、そのまま残されます。

ここでユーザーがMDBListener2を再開すると、接続マネージャーは空きプールからリスナーに接続を渡します。

EntirePoolに設定されたパージ・ポリシー

これはさらにおもしろい動作です。3つのMDBがアプリケーション・サーバーにインストールされ、それぞれ独自のリスナー・ポートを使用しているとします。これらのリスナー・ポートはjms/CF1ファクトリーから接続を作成しました。数分後、MDBListener1が停止し、その接続c1がjms/CF1の空きプールに入れられます。

MDBListener2は、ネットワーク・エラーを検出すると、自身をシャットダウンしてc2を閉じます。接続マネージャーは、今度は空きプール内の接続を閉じます。ただし、MDBListener3で使用されている接続はそのまま残されます。

パージ・ポリシーを何に設定するべきか

前述のように、JMS接続プールのパージ・ポリシーのデフォルト値はFailingConnectionOnlyです。しかし、パージ・ポリシーはEntirePoolに設定することをお勧めします。なぜなら、アプリケーションがJMSプロバイダーへの接続にネットワーク・エラーを検出すると、ほとんどの場合、同じ接続ファクトリーから作成されたすべてのオープン接続でも同じ問題が発生する傾向があるためです。パージ・ポリシーがFailingConnectionOnlyに設定されていると、接続マネージャーは空きプール内のすべての接続をそのまま残します。次回、アプリケーションがJMSプロバイダーへの接続を作成しようとすると、接続マネージャーは空きプール内に接続があればその接続を渡します。しかし、アプリケーションがそれを使用しようとすると、アプリケーションと同じネットワークの問題が発生します。

では同じ状況でパージ・ポリシーがEntirePoolに設定されている場合を考えてみましょう。最初のアプリケーションがネットワークの問題を検出するとすぐに、接続マネージャーは問題を検出した接続を廃棄し、ファクトリーの空きプール内の接続をすべて閉じます。新規アプリケーションが開始され、ファクトリーから接続を作成しようとすると、空きプールが空であるため、接続マネージャーは新規接続の作成を試みます。ネットワークの問題が解決されていれば、アプリケーションに渡される接続は有効になります。

上に戻る

拡張接続プール・プロパティー

WebSphere Application Server V6には、以下で説明するように、拡張接続プール・プロパティーがいくつか導入されています。

サージ保護

ejbCreate()メソッドの一環として、同じ接続ファクトリーからJMS接続を作成する、50のEJBがあるとします。これらのBeanがすべて同時に作成され、ファクトリーの空き接続プール内に接続が1つもない場合、アプリケーション・サーバーは同じJMSプロバイダーへの50個のJMS接続を同時に作成しようとするため、WebSphere Application ServerとJMSプロバイダーの両方にかなりの負荷がかかります。

サージ保護プロパティーでは、接続ファクトリーから同時に作成可能なJMS接続の数を制限し、追加接続の作成を、時間をずらして行うことによって、このような状態を回避できます。これは、サージしきい値とサージ作成間隔という2つのプロパティーを使用して行います。

EJBアプリケーションが接続ファクトリーからJMS接続を作成しようとすると、接続マネージャーは作成されている接続数を確認します。その数がサージしきい値プロパティーの値以下である場合、接続マネージャーは新規接続のオープンを続行します。しかし、作成されている接続数がサージしきい値プロパティーを上回る場合、接続マネージャーはサージ作成間隔プロパティーに指定された時間だけ待機してから新規接続を作成してオープンします。

この記事シリーズのパート1の図2には、アプリケーションが ConnectionFactory.createConnection()を呼び出すと発生するタスクが示されています。以下の図は、サージ・プロパティーがこのプロセスにどのように組み込まれているかを示す、より詳細なダイアグラムです。

滞留接続

WebSphere Application Server V6には、「滞留している」JMS接続を検出する方法が用意されています。この機能を使用するには、滞留タイマー時間、滞留時間、および滞留しきい値の3つのプロパティーを設定する必要があります。ところで、滞留しているJMS接続とは正確にはどのようなものでしょうか。JMS接続が滞留していると見なされるのは、JMSアプリケーションがその接続を使用してJMSプロバイダーに要求を送信し、そのプロバイダーが特定の時間内に応答しない場合です。

この記事シリーズのパート1では、プール維持スレッドについて説明しました。これは定期的に実行され、接続ファクトリーの空きプール内をチェックして、ある期間使用されていない接続または開かれている期間が長すぎる接続を探します。滞留接続を検出するため、アプリケーション・サーバーは滞留接続スレッドも管理します。これは、接続ファクトリーから作成されたすべてのアクティブな接続の状態をチェックして、それらのいずれかがJMSプロバイダーからの応答を待っているかどうかを調べます。応答を待っている接続が見つかると、スレッドはその接続の待機時間を判別し、その時間を滞留時間プロパティーの値と比較します。

JMSプロバイダーの応答にかかる時間が、滞留時間プロパティーに指定された時間を上回る場合、アプリケーション・サーバーは 、そのJMS接続を滞留としてマークします。滞留接続スレッドの実行間隔はどれくらいでしょうか。実行間隔は、滞留タイマー時間プロパティーの値で決まります。デフォルト値は0であり、これは滞留接続の検出が使用不可であることを意味します。例えば、接続ファクトリーjms/CF1の滞留タイマー時間プロパティーが10に、滞留時間プロパティーが15に設定されているとします。滞留接続スレッドは10秒ごとに開始され、jms/CF1から作成された接続がWebSphere MQからの応答を15秒より長く待っていないかどうかを調べます。

EJBがjms/CF1を使用してWebSphere MQへのJMS接続を作成し、Connection.createSession()を呼び出すことにより、その接続を使用してJMSセッションを作成しようとするとします。しかし、何らかの原因でJMSプロバイダーは要求に応答できなくなっています。おそらく、マシンがフリーズしたか、JMSプロバイダー上で実行中のプロセスがデッドロック状態であるため、新規作業を処理できなくなっています。

EJBがConnection.createSession()を呼び出してから10秒後、滞留接続スレッドが起動し、jms/CF1から作成されたアクティブな接続を調べます。アクティブな接続は1つ(c1)のみです。EJB1はc1を使用して送信した要求への応答を10秒待っており、これは滞留時間の値を下回るため、滞留接続スレッドはこの接続を無視し、スリープ状態に戻ります。

10秒後、滞留接続スレッドがもう一度開始され、jms/CF1のアクティブな接続を調べます。今回も、接続は1つ(c1)のみです。EJB1がcreateSession()を呼び出してから20秒経過しており、まだ応答を待っています。20秒は滞留時間プロパティーに指定された時間を上回るため、滞留接続スレッドはc1を滞留としてマークします。

5秒後、WebSphere MQがようやく応答し、EJB1がJMSセッションを作成できるとします。接続は使用中の状態に戻ります。

アプリケーション・サーバーは、接続ファクトリーから作成したJMS接続のうち、滞留している接続の数を数えます。アプリケーションがその接続ファクトリーを使用して新規JMS接続を作成するときに、ファクトリーの空きプール内に空き接続がない場合、接続マネージャーは滞留接続の数と滞留しきい値プロパティーの値を比較します。滞留接続の数が滞留しきい値を下回る場合、接続マネージャーは新規接続を作成し、それをアプリケーションに渡します。しかし、滞留接続の数が滞留しきい値と等しい場合、アプリケーションはリソース例外を受け取ります。下の図10は、滞留しきい値がJMS接続の作成方法に及ぼす影響を示しています。

プール区画

WebSphere Application Server V6には、接続ファクトリーの空き接続プールを区切るために2つのプロパティーが用意されています。「空きプール区画の数」と、「空きプール分配テーブル・サイズ」です。最初のプロパティーは、空き接続プールをいくつの区画に分割するかをアプリケーション・サーバーに伝え、2つ目のプロパティーは区画の索引付け方法を決定します。IBMサポートから変更の要請がない限り、これらのプロパティーはデフォルト値の0のままにしてください。

追加された拡張接続プール・プロパティーは「共有区画の数」と呼ばれ、共有接続の保管に使用する区画数を指定します。JMS接続は常に非共用であり、これは一度に1つのアプリケーションでしか使用できないことを意味するため、このプロパティーは適用されません。

上に戻る

JMS接続とWebSphere MQ

次のセクションには、JMSプロバイダーとしてWebSphere MQを使用するユーザー向けの情報を記載します。

JMS接続とWebSphere MQクライアント・チャネル

よくある質問として、「WebSphere MQ JMS 接続ファクトリーがCLIENTトランスポートを使用するよう構成されている場合、JMS接続はWebSphere MQクライアント・チャネルにどのように関連付けられますか」というものがあります。

一般的な原則では、WebSphere Application ServerからWebSphere MQへの各JMS接続がクライアント・チャネルを使用します。したがって、実行中のアプリケーションが2つあり、どちらも同じ接続ファクトリーから接続が作成されている場合、2つのクライアント・チャネルが使用されます。接続ファクトリーの最大接続数プロパティーでは、ファクトリーから作成可能なJMS接続の最大数が指定されます。各接続がクライアント接続に関連付けられているため、このファクトリーで使用できるクライアント・チャネルの最大数は、最大接続数と同じです。

JMS接続が同時に使用するクライアント・チャネルの最大数を判別するには、同じキュー・マネージャーを指す全ての接続ファクトリーの最大接続数プロパティー値を合計します。例えば、jms/CF1とjms/CF2という2つの接続ファクトリーがあり、どちらも同じWebSphere MQキュー・マネージャーを使用しているとします。これらのファクトリーはデフォルトの接続プール・プロパティーを使用しています。デフォルトの最大接続数は10に設定されています。すべての接続が、jms/CF1とjms/CF2の両方から同時に使用される場合、WebSphere MQへのアクティブなクライアント・チャネルは20になります。

JMS接続とWebSphere MQ接続プール

デフォルトでは、WebSphere MQ JMS接続ファクトリーから作成された接続は、アプリケーション・サーバー・プールとWebSphere MQ接続プールの2つのレベルのプールに従属します。これはどういう意味でしょうか。

JMSプロバイダーへの接続は、アプリケーション・サーバーによってプールされます。アプリケーションが接続を終了すると、その接続は接続ファクトリーの空きプールに入れられます。通常は、その後別のアプリケーションによって再利用されるか、未使用タイムアウト・プロパティー値より長く空きプール内に残っていれば閉じられます。しかし、WebSphere MQに対して作成されたJMS接続の未使用タイムアウトが経過した場合、接続は閉じられない代わりに、アプリケーション・サーバー・プールから取り出され、WebSphere MQ接続プールに入れられます。

アプリケーションがWebSphere MQ接続ファクトリーから新規接続を作成するときに、ファクトリーの空きプール内に接続がない場合、アプリケーションはWebSphere MQ接続プール内で必要なキュー・マネージャーへの空き接続を探します。接続が見つかると、WebSphere MQ接続プールから取り出され、アプリケーションに渡されます。

接続ファクトリーごとに個別の空きプールがあるのではなく、アプリケーション・サーバーごとに単一のWebSphere MQ接続プールが存在します。このプールには、関連付けられたプール維持スレッドもあります（WebSphere MQの用語では、このスレッドはプール・スカベンジャー・スレッドと呼ばれますが、混乱を避けるためにプール維持スレッドと見なすことができます）。このスレッドは定期的に実行され、WebSphere MQ接続プール内の接続を調べて、30分より長く存続しているものがないか確認し、該当する接続があれば閉じます。

きっと、「このやり方はアプリケーション・サーバー・プールに対する未使用タイムアウトの機能に似ている」と思われることでしょう。それは一部正しいのですが、紛らわしいことに、未使用タイムアウト・プロパティーはWebSphere MQ接続プール内にある接続の存続時間には効力がありません。それらの接続の存続時間は、「メッセージ・リスナー・サービス」のカスタム・プロパティー mqjms.pooling.timeoutによって判別されます。このプロパティーの設定方法の詳細は、WebSphere Application Server インフォメーション・センターを参照してください。

以下の図は、WebSphere MQをJMSプロバイダーとして使用する場合に関与する、2つのレベルの接続プールを示しています。

WebSphere MQへのJMS接続の作成には時間がかかる場合があり、1秒より長くなることもあります。主幹業務システムでは、この遅延によりメッセージ処理時間に大きな差が生じる可能性があります。アプリケーション・サーバーごとに単一のWebSphere MQ接続プールを置くことは、このプール内の空き接続を、同じWebSphere MQキュー・マネージャーにマップされている接続ファクトリー間で共用できることを意味します。接続ファクトリーの空き接続プールに空き接続が存在しない場合、必要なキュー・マネージャーへの空き接続がWebSphere MQ接続プール内に存在する可能性があり、それを取り出してアプリケーションに渡すことができます。

前述のように、デフォルトではWebSphere MQ接続プールは使用可能になっています。プールを使用不可にする方法は、WebSphere Application Serverのバージョンによって以下のように異なります。

• V6の場合、WebSphere MQ JMS接続ファクトリーのプロパティー「MQ接続プールを使用可能にする」の選択を解除します。
• V5.1.1の場合、「メッセージ・リスナー・サービス」のカスタム・プロパティー mqjms.pooling.thresholdを0に設定します。詳しくは、WebSphere Application Server インフォメーション・センターを参照してください。

アプリケーション・サーバーごとに単一のWebSphere MQ空き接続プールがあることを思い出してください。いずれかのWebSphere MQ接続ファクトリーがWebSphere MQ接続プールを使用するよう構成されている場合、WebSphere MQプールを使用するよう構成されているファクトリーからの接続だけでなく、WebSphere MQへのすべてのJMS接続がプールされます。この動作は、WebSphere MQ接続プールの機能です。その動作を以下の例で示します。

MDBListener1とMDBListener2という2つのMDBリスナーがあり、どちらも接続ファクトリー jms/CF1を使用しているとします。MDBListener1は実行中であり、WebSphere MQへの接続c1を使用しているのに対して、MDBListener2は停止しています。MDBListener1がシャットダウンすると、接続はオープンされたままjms/CF1の空きプールに入れられます。

c1が、未使用タイムアウト・プロパティーに指定された時間より長くjms/CF1の空きプールに存続しているとします。プール維持スレッドが実行されると、接続を検出し、それを閉じようとします。この時点で、WebSphere MQは接続を閉じるための呼び出しをインターセプトし、代わりにその接続を自身の空きプールに入れます。

次にMDBListener2が開始され、接続ファクトリー jms/CF1から接続を作成しようとします。このファクトリーの空きプールには接続が存在しないため、接続マネージャーはWebSphere MQ空きプール内を探してc1を検出します。この接続は、MDBListener2が使用を希望するファクトリーから作成されたため、WebSphere MQ空きプールから除去されてリスナーに渡されます。

上に戻る

まとめ

このシリーズのパート2では、問題のある接続が検出されたときに、パージ・ポリシーを使用して空き接続プールの接続を廃棄する方法と、拡張接続プール・プロパティーを使用して、滞留接続を検出したり、同時に作成可能なJMS接続数を制限したりする方法について説明しました。最後に、この記事では、WebSphere Application ServerからのJMS接続をWebSphere MQクライアント・チャネルにマップする方法と、WebSphere Application Serverで提供されるプール機能にWebSphere MQ接続プールのメカニズムが及ぼす影響について説明しました。

参考文献

• developerWorks Japan: WebSphere: WebSphereの日本の技術情報サイトです
  
  
• developerWorks: WebSphere(US) : WebSphereの英語の技術情報サイトです
  
  
• WebSphere Application Server および WebSphere MQ とともにJMS接続プールを使用する（パート1）
  
  
• メッセージ駆動型Beanがメッセージを厳密な順序で処理するようにWebSphere Application Serverを構成する（Configure WebSphere Application Server to make message-driven beans process messages in a strict order）（US）
  
  
• WebSphere Application ServerでMDBリスナーがリスナー・ポートと連携する方法（How MDB listeners work with a listener port in WebSphere Application Server）（US）
  
  
• WebSphere Application Serverによるポイズン・メッセージの処理方法（How WebSphere Application Server handles poison messages）（US）
  
  
• リスナー・ポートでの最大セッション数プロパティーがWebSphere Application Serverのパフォーマンスに与える影響（How the maximum sessions property on the listener port affects WebSphere Application Server performance）（US）
  
  
• Bobby WoolfによるJMS関連のブログ（US）
  
  
• WebSphere Application Server 開発者向け資料ページ（US）
  WebSphere Application Server の使用に役立つ技術資料。
  
  
• WebSphere Application Server 製品ページ（US）
  製品説明、製品ニュース、トレーニング情報、サポート情報など。
  
  
• WebSphere Application Server インフォメーション・センター（US）
  WebSphere Application Serverのインストール、構成、および使用に関する概念情報、タスク情報、および参照情報などのすべてのWebSphere Application Server資料への単一のEclipseベースのWebポータル。
  
  
• WebSphere Application Server インフォメーション・ロードマップ（US）
  インストール、マイグレーション、管理、開発、トラブルシューティング、および基礎テクノロジーの理解に役立つ記事および資料のロードマップ。
  
  
• WebSphere Application Server 資料ライブラリー（US）
  WebSphere Application Server 製品マニュアル。
  
  
• WebSphere Application Server サポート（US）
  サポート問題およびその解決策の検索可能なデータベース、ダウンロード、フィックス、問題追跡など。
  
  
• WebSphere MQ 開発者向け資料ページ（US）
  ほぼすべてのプラットフォームのアプリケーション、Webサービス、およびトランザクションを統合するために、WebSphere MQを使用してメッセージング・ミドルウェアを設計、開発、およびデプロイするのに役立つ技術資料。
  
  
• WebSphere MQ 製品ページ（US）
  製品説明、製品ニュース、トレーニング情報、サポート情報など。
  
  
• WebSphere MQ V6 試用ダウンロード（US）
  WebSphere MQ V6の無料の試用ダウンロード。試用期間中は、Windows®版およびLinux®版のインストール済み環境について限定的なオンライン・サポートを無料で受けられます。
  
  
• WebSphere MQ V6 インフォメーション・センター（US）
  WebSphere MQ環境のインストール、構成、および使用に関する概念情報、タスク情報、および参照情報などのすべてのWebSphere MQ V6資料への単一のEclipseベースのWebポータル。
  
  
• WebSphere MQ 資料ライブラリー（US）
  WebSphere MQ 製品マニュアル。
  
  
• WebSphere MQ サポートパック（US）
  WebSphere MQ 製品ファミリーのダウンロード可能なコード、資料、およびパフォーマンス・レポート。
  
  
• WebSphere MQ 公開ニュースグループ（US）
  非IBMフォーラム。WebSphere MQについての技術的な質問の回答の入手、およびWebSphere MQに関する自分の知識の、ほかのユーザーとの共有ができます。
  
  
• developerWorksのWebSphere Business Integrationのゾーン（US）
  WebSphere Business Integrationの手引き記事、ダウンロード、チュートリアル、研修、製品情報など（開発者向け）。
  
  
• WebSphere Business Integration 製品ページ（US）
  すべてのWebSphere Business Integration製品の便利な概要（ビジネス・ユーザーとテクニカル・ユーザーの両者向け）。
  
  
• WebSphereフォーラム（US）
  製品固有のフォーラム。技術的な質問の回答の入手、および自分の専門知識の、ほかのWebSphereユーザーとの共有ができます。
  
  
• 最も人気のあるWebSphere試用版のダウンロード。（US）
  主要なWebSphere製品を無料で試用ダウンロードできます。
  
  
• IBM ソフトウェア製品の試用ダウンロード（US）
  厳選されたIBM® DB2®、Lotus®、Rational®、Tivoli®、および WebSphere®製品を無料で試用ダウンロードできます。
  
  
• IBM Press 発行の技術書（US）
  Barnes & Nobleを介した便利なオンライン注文。
  
  
• developerWorksのテクニカル・イベントおよびWebcast（US）
  IBMの専門家による無料のテクニカル・セッション。ユーザーの学習曲線を加速し、最難関のソフトウェア・プロジェクトで成功を修めるのに役立ちます。セッションには、1時間のWebcastから、世界中の都市での半日および1日のライブ・セッションまであります。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• 接続プールのパージ・ポリシー
• FailingConnectionOnlyに設定されたパージ・ポリシー
• 拡張接続プール・プロパティー
• JMS接続とWebSphere MQ
• まとめ
• 参考文献
• 著者について
• コメント