Paul Titheridge, Software Development Engineer, WebSphere MQ Support team",
IBM WebSphere and Java Messaging Support
2007年9月26日, 原文はこちら（US）
この2部構成の記事では、JMS接続プールがWebSphere Application ServerおよびWebSphere
MQでどのように機能するかについて説明します。パート2では、接続プールのエラー処理、同時接続要求を処理するためのプールの構成、およびWebSphere
Application ServerによるWebSphere MQへのJMS接続の管理について説明します。
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」に設定します。
パージ・ポリシーの設定値による動作のいくつかの例を以下に示します。
パート1の例を使用して、2つのMDBがアプリケーション・サーバーにデプロイされ、それぞれ異なるリスナー・ポートを使用しているとします。リスナー・ポートはすべて、jms/CF1接続ファクトリーを使用します。10分後、MDBListener1が停止し、このリスナー・ポートが使用していた接続が接続プールに返されます。
図1 MDBListener1が停止し、接続c1がjms/CF1の空きプールに入れられる
MDBListener2がJMS宛先にポーリング中にネットワーク・エラーが発生します。どうなるでしょうか。リスナー・ポートはシャットダウンし、jms/CF1接続ファクトリーのパージ・ポリシーがFailingConnectionOnlyに設定されているため、接続マネージャーはMDBListener2で使用されていた接続のみを廃棄します。空きプール内の接続は、そのまま残されます。
図2 接続エラーのためMDBListener2が停止し、接続c2が閉じられる。接続c1は空きプール内に残される。
ここでユーザーがMDBListener2を再開すると、接続マネージャーは空きプールからリスナーに接続を渡します。
図3 MDBListener2が再開し、空きプールから接続c1を取得する。
EntirePoolに設定されたパージ・ポリシー
これはさらにおもしろい動作です。3つのMDBがアプリケーション・サーバーにインストールされ、それぞれ独自のリスナー・ポートを使用しているとします。これらのリスナー・ポートはjms/CF1ファクトリーから接続を作成しました。数分後、MDBListener1が停止し、その接続c1がjms/CF1の空きプールに入れられます。
図4 MDBListener1が停止し、接続c1がjms/CF1の空きプールに入れられる。
MDBListener2は、ネットワーク・エラーを検出すると、自身をシャットダウンしてc2を閉じます。接続マネージャーは、今度は空きプール内の接続を閉じます。ただし、MDBListener3で使用されている接続はそのまま残されます。
図5 ネットワーク・エラーが原因でMDBListener2が停止したため、接続c2が閉じられる。接続c1も閉じられ、c3は開いたまま残される。
パージ・ポリシーを何に設定するべきか
前述のように、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()を呼び出すと発生するタスクが示されています。以下の図は、サージ・プロパティーがこのプロセスにどのように組み込まれているかを示す、より詳細なダイアグラムです。
図6 サージ保護を有効にした場合の空き接続プールからのJMS接続の取得
滞留接続
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プロバイダー上で実行中のプロセスがデッドロック状態であるため、新規作業を処理できなくなっています。
図7 時間0秒。EJB1がc1を使用してcreateSession()を呼び出す
EJBがConnection.createSession()を呼び出してから10秒後、滞留接続スレッドが起動し、jms/CF1から作成されたアクティブな接続を調べます。アクティブな接続は1つ(c1)のみです。EJB1はc1を使用して送信した要求への応答を10秒待っており、これは滞留時間の値を下回るため、滞留接続スレッドはこの接続を無視し、スリープ状態に戻ります。
10秒後、滞留接続スレッドがもう一度開始され、jms/CF1のアクティブな接続を調べます。今回も、接続は1つ(c1)のみです。EJB1がcreateSession()を呼び出してから20秒経過しており、まだ応答を待っています。20秒は滞留時間プロパティーに指定された時間を上回るため、滞留接続スレッドはc1を滞留としてマークします。
図8 時間20秒。EJB1がWebSphere MQからの応答を待っている時間が15秒より長いため、c1は滞留としてマークされる。
5秒後、WebSphere MQがようやく応答し、EJB1がJMSセッションを作成できるとします。接続は使用中の状態に戻ります。
図9 時間30秒。25秒後、WebSphere MQがようやく応答したため、次に滞留接続スレッドが実行されるときにはc1がもう一度アクティブとしてマークされる。
アプリケーション・サーバーは、接続ファクトリーから作成したJMS接続のうち、滞留している接続の数を数えます。アプリケーションがその接続ファクトリーを使用して新規JMS接続を作成するときに、ファクトリーの空きプール内に空き接続がない場合、接続マネージャーは滞留接続の数と滞留しきい値プロパティーの値を比較します。滞留接続の数が滞留しきい値を下回る場合、接続マネージャーは新規接続を作成し、それをアプリケーションに渡します。しかし、滞留接続の数が滞留しきい値と等しい場合、アプリケーションはリソース例外を受け取ります。下の図10は、滞留しきい値がJMS接続の作成方法に及ぼす影響を示しています。
図10 滞留接続の検出を有効にした場合の空き接続プールからのJMS接続の取得
プール区画
WebSphere Application Server V6には、接続ファクトリーの空き接続プールを区切るために2つのプロパティーが用意されています。「空きプール区画の数」と、「空きプール分配テーブル・サイズ」です。最初のプロパティーは、空き接続プールをいくつの区画に分割するかをアプリケーション・サーバーに伝え、2つ目のプロパティーは区画の索引付け方法を決定します。IBMサポートから変更の要請がない限り、これらのプロパティーはデフォルト値の0のままにしてください。
追加された拡張接続プール・プロパティーは「共有区画の数」と呼ばれ、共有接続の保管に使用する区画数を指定します。JMS接続は常に非共用であり、これは一度に1つのアプリケーションでしか使用できないことを意味するため、このプロパティーは適用されません。
次のセクションには、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つのレベルの接続プールを示しています。s
図11 WebSphere Application ServerおよびWebSphere MQ JMS接続プール
WebSphere MQへのJMS接続の作成には時間がかかる場合があり、1秒より長くなることもあります。主幹業務システムでは、この遅延によりメッセージ処理時間に大きな差が生じる可能性があります。アプリケーション・サーバーごとに単一のWebSphere MQ接続プールを置くことは、このプール内の空き接続を、同じWebSphere MQキュー・マネージャーにマップされている接続ファクトリー間で共用できることを意味します。接続ファクトリーの空き接続プールに空き接続が存在しない場合、必要なキュー・マネージャーへの空き接続がWebSphere MQ接続プール内に存在する可能性があり、それを取り出してアプリケーションに渡すことができます。
前述のように、デフォルトではWebSphere MQ接続プールは使用可能になっています。プールを使用不可にする方法は、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の空きプールに入れられます。
図12 MDBListener1が停止し、接続c1がjms/CF1の空きプールに入れられる。
c1が、未使用タイムアウト・プロパティーに指定された時間より長くjms/CF1の空きプールに存続しているとします。プール維持スレッドが実行されると、接続を検出し、それを閉じようとします。この時点で、WebSphere MQは接続を閉じるための呼び出しをインターセプトし、代わりにその接続を自身の空きプールに入れます。
図13 接続マネージャーが接続をWebSphere MQ空きプールに入れる
次にMDBListener2が開始され、接続ファクトリー jms/CF1から接続を作成しようとします。このファクトリーの空きプールには接続が存在しないため、接続マネージャーはWebSphere MQ空きプール内を探してc1を検出します。この接続は、MDBListener2が使用を希望するファクトリーから作成されたため、WebSphere MQ空きプールから除去されてリスナーに渡されます。
このシリーズのパート2では、問題のある接続が検出されたときに、パージ・ポリシーを使用して空き接続プールの接続を廃棄する方法と、拡張接続プール・プロパティーを使用して、滞留接続を検出したり、同時に作成可能なJMS接続数を制限したりする方法について説明しました。最後に、この記事では、WebSphere Application ServerからのJMS接続をWebSphere MQクライアント・チャネルにマップする方法と、WebSphere Application Serverで提供されるプール機能にWebSphere MQ接続プールのメカニズムが及ぼす影響について説明しました。
|
Paul Titheridgeは、エクセター大学を卒業後、1995年9月にIBMに入社しました。PaulはVoice and
Business Integration部門に勤務後、現在、WebSphereおよびJavaメッセージングのサポート・チームのメンバーとして、WebSphere
MQおよびWebSphere Application Serverを使用するお客様の問題を解決しています。
|
