ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server JMSのプログラミング
11g リリース1(10.3.3)
B61629-01
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		  

D 分散キューでのJMS宛先可用性ヘルパーAPIの使用

次の項では、宛先が使用可能または使用不可の場合に通知を取得する手段を提供するJMSDestinationAvailabilityHelper APIの使用方法について説明します。


注意:

このガイドには、経験豊富なJMS開発者向けの高度な情報が記載されています。分散キューと相互運用する際はメッセージドリブンBeanを使用することをお薦めします。MDBコンテナは、分散キューのすべてのメンバー間で内部コンシューマを必要に応じて自動的に作成して閉じます。また、セキュリティ、スレッド化、プーリング、アプリケーション・ライフサイクル、自動再接続、トランザクションのリスト化も処理します。MDBを使用できない場合、より簡単な回避策(分散キューでコンシューマをリバランスするようにコンシューマを定期的に再起動したり、メッセージの順序付けやパフォーマンスを気にしない場合は、分散キューの転送オプションを有効にしたりするなど)も検討できます。

はじめに

分散キュー(DQ)は、単一の論理宛先としてアクセスされるJMS物理キューのグループです。メッセージはメンバー間でロード・バランシングされ、クライアントはメンバー宛先間でフェイルオーバーできます。

MDBを利用しない分散宛先ユーザーの場合、コンシューマ・アプリケーションに関する問題が生じることがあります。たとえば、次のような問題があります。

こうした使用事例を解決するために、WebLogic Serverには、JMS宛先可用性ヘルパーAPIが用意されています。

DQプロデューサ・ロード・バランシングの制御

コンシューマ・ロード・バランシングについて説明する前に、プロデューサ・ロード・バランシングの基本事項とベスト・プラクティスを最初に確認しておくと便利です。

基本のJMS

JMSプログラムは、次の3つの段階でメッセージ送信を設定します。

  1. クライアントは、JMS接続ファクトリを使用してWebLogicへのJMS接続を作成します。

  2. クライアントはこの接続を使用して、JMSのセッションとセンダーを作成します。

  3. クライアントは、このセンダーを使用してメッセージを送信します。

WebLogic JMSでは、クライアントが接続するWebLogicサーバーはクライアントの接続ホストと呼ばれ、メッセージは常にセンダーからその接続ホストを介して、接続ホストと同じクラスタ内の宛先にルーティングします。接続は、その有効期間中は接続ホストに固定されます。

WebLogic接続ファクトリは、1つ以上のWebLogicサーバーでターゲット指定できます。接続ファクトリがターゲット指定される同じWebLogicサーバーでクライアントが実行している場合、ファクトリは常に、クライアントと同じサーバーの接続ホスト(接続はローカル)で接続を返します。一方で、接続ファクトリのターゲットに含まれるWebLogicサーバーでクライアントが実行していない場合、ファクトリはターゲット間で自動的にロード・バランシングして、そのいずれかに接続を返します。

分散キュー(DQ)へのセンダー

センダーが分散宛先で機能する場合、各メンバーのJNDI名に送信するのではなく、DQのJNDI名(その論理名)に常に送信します。これにより、ロード・バランシング動作の自動化が可能になります。

DQに対するセンダーのデフォルト動作では、メンバーがセンダーの接続ホストで実行する場合、すべての送信メッセージはいずれかのローカル・メンバーに送信されます。それ以外の場合、メッセージはすべてのメンバー間でラウンドロビンします。

ローカル・メンバーがセンダーの接続ホストに存在する場合でも、同じDQセンダーのメッセージをすべてのアクティブなメンバー間でラウンドロビンするようにするには、Server Affinityをfalseに、Load Balanceをtrueに設定してカスタム接続ファクトリを使用します。

JMS宛先可用性ヘルパーAPIの使用

次の項では、JMSDestinationAvailabilityHelper APIの使用方法について説明します。

概要

クライアントのjavax.jms APIを使用してコンシューマを作成し、DQ論理JNDI名を指定した場合、コンシューマはアクティブなDQメンバーにロード・バランシングされ、その存続期間中は該当メンバーに固定されます。すべてのコンシューマの作成後に新しいメンバーがアクティブになる場合、新しいメンバーにコンシューマはありません。

JMSDestinationAvailabilityHelper APIにより、宛先が使用可能または使用不可になる場合に通知を取得する手段が提供されます。これらの通知は、アプリケーションを初期化したときに使用不可のメンバーが存在する場合でもすべてのDQメンバーでアプリケーションがコンシューマを作成する際に役立ちます。同じメカニズムを使用して、他のタイプの宛先(WebLogic分散宛先のみではなく、通常の宛先や外部ベンダーの宛先)の可用性を検出することもできます。

アプリケーションは、JNDIコンテキスト・パラメータと宛先のJNDI名を指定して、ヘルパーに通知リスナーを登録します。DQについては、メンバーが使用可能および使用不可になる場合、アンデプロイされる場合、新しいメンバーとして追加される場合、移行、停止、再起動する場合に、ヘルパーによってリスナーに通知されます。

WebLogic ServerのMDBは、両方のローカルMDB (DQと同じクラスタにデプロイされたMDB)とリモートMDB (DQをホストするクラスタとは別のクラスタにデプロイされたMDB)に同じメカニズムを内部で使用することに注意してください。MDBには、JMSDestinationAvailabilityHelper APIが提供する同じ動的適応性をDQトポロジ変更に対して実現する即時利用可能なソリューションがあります。

一般的なフロー

JMSDestinationAvailabilityHelper APIを使用するアプリケーションは、次の一般的なステップに従います。

  1. 下記のステップ3の動作を実現するため、weblogic.jms.extensions.DestinationAvailableListenerインタフェースを実装します。

  2. JNDIコンテキスト・プロパティ(通常はURLとコンテキスト・ファクトリのみ)、宛先のJNDI名、リスナー・インスタンスを指定して、ヘルパーに関連事項を登録します。クライアントがDQと同じクラスタで実行している場合はURLを指定しないでください。

    import java.util.Hashtable;
import javax.naming.Context;
import weblogic.jms.extensions.JMSDestinationAvailabilityHelper;

Hashtable contextProps = new Hashtable();
contextProps.put(javax.naming.Context.PROVIDER_URL, myURL);
contextProps.put(Context.INITIAL_CONTEXT_FACTORY,                 "weblogic.jndi.WLInitialContextFactory");
JMSDestinationAvailabilityHelper dah =    JMSDestinationAvailabilityHelper.getInstance();

RegistrationHandler rh = dah.register(
   contextProperties,
   destinationJNDIName,
   myDestinationAvailableListener
)

  3. リスナー・コールバックを処理します。コールバックは単一スレッド化されるため、2つのコールバックが同時に生じることはありません。

    1. onDestinationsAvailable() - 通常は最初の通知。このコールバックの実装は、指定の各宛先でゼロ以上のコンシューマを作成すると反応するのが一般的です。これが失敗した場合、定期的に再試行します。

    2. onDestinationsUnavailable() - このコールバックは、通常、宛先で既存のコンシューマを破棄する場合に使用されます。

    3. onFailure() - このコールバックは、通常、生じた失敗のログを記録する場合に使用されます。ヘルパーは引き続き内部で再試行し、以降のコールバックを行いますが、管理者は失敗を確認する必要があります。ヘルパーは、最善を尽くして、繰り返される同じ失敗に対してonFailure()を一度呼び出します。

  4. 完了したら、rh.unregister()を呼び出して宛先の関連事項の登録を解除します。

weblogic.jms.extension.DestinationDetailの処理

前述のように、onDestinationsAvailable()通知は、スタンドアロンの宛先、外部宛先、分散宛先のメンバーが使用可能になることを示します。通知はDestinationDetailインスタンスのリストで構成され、キー情報は各DetailでgetDestinationType()、getJNDIName()、isLocalWLSServer()、isLocalCluster()を呼び出すことで取得されます。

宛先の詳細は、呼出し元が行うアクションの決定に役立ちます。宛先のタイプがDD_QUEUEの場合、詳細のgetJNDIName()メソッドにより、特定のDQメンバーのJNDI名が返されます。呼出し元はアプリケーション・コンシューマのインスタンスをメンバーにデプロイできる場合とできない場合があります。宛先のタイプがPHYSICALまたはFOREIGNの場合、アプリケーションは宛先を通常の宛先として扱います。

特にDQで使用する場合、DestinationDetailのコロケーション・フラグを利用することを強くお薦めします。宛先のコロケーションの性質を判断するには、isLocalWLSServer()とisLocalCluster()を呼び出します。「ローカル・サーバー・コンシューマのベスト・プラクティス」を参照してください。

APIとそのメソッドの詳細は、Oracle Fusion Middleware Oracle WebLogic Server APIリファレンスのDestinationDetailに関する項を参照してください。

コンシューマ・コンテナのベスト・プラクティス

次の項では、コンシューマ・コンテナのベスト・プラクティスのガイドラインを示します。

登録と登録解除のタイミング

  1. アプリケーションのデプロイメント時にJMSDestinationAvailabilityHelperに登録します。ヘルパーがリスナーでonFailure()コールバックを呼び出す場合、デプロイメントを失敗しないでください(断続的な失敗になると想定されます)。

  2. アプリケーションのアンデプロイメント時にJMSDestinationAvailabilityHelperへの登録を解除します。

URLの処理

  1. クライアントが宛先と同じサーバーまたは同じクラスタで実行している場合、ヘルパーへの登録やJNDIコンテキストの作成時にURLを指定しないでください。これにより、ヘルパーは確実にローカル・コンテキストを作成します。

  2. isLocalCluster()またはisLocalServer()がtrueを返しても、URLを指定した場合(この場合URLは不要)、1つの警告ログと見なします。

失敗の処理

  1. onFailure()通知で報告されるエラーのログを記録するため、アプリケーションの開発者は、構成/アプリケーションのエラーを修正することができます。同じ例外のログを繰り返し記録することは避けてください。ヘルパーは引き続き内部で再試行し、成功または異なるタイプの失敗に対して以降のコールバックを行いますが、管理者は失敗を確認する必要があります。エラーは、不正なURL、無効なセキュリティ情報、存在しない宛先などのアプリケーションまたは管理上のエラーが原因で発生します。また、JNDIコンテキストのホストまたは宛先が一時的に使用不可になる場合にも発生します。

  2. JMS呼出しが例外をスローするか、JMS接続例外リスナーが接続の失敗を報告した場合、接続を閉じます。すべてのリソースの誤りが修正されたら、すべてのリソースを定期的に再初期化します。再初期化には、通常、コンテキストの作成、JNDIルックアップの実行、接続、セッション、コンシューマの作成が必要です。

  3. 失敗後すぐに再試行することは避けてください。かわりに数秒ごとに定期的に再試行して、サーバーがオーバーロードしないようにします。

JNDIコンテキストの処理

  1. JNDIルックアップの複数のスレッドで同じJNDIコンテキストを共有します。

  2. アンデプロイ時にコンテキストでclose()を呼び出して、メモリー・リークを防止します。

  3. コンテキストでclose()を呼び出して、失敗時(ルックアップの失敗を含む)に再作成します。

JMS接続の処理

  1. JMS接続の場合、標準のJMS接続「例外リスナー」を必ず登録します。

  2. onException()で接続を閉じてJNDIルックアップを定期的に再試行し、JMS接続を再作成して別のスレッドでコンシューマを設定します。

  3. アンデプロイ時に接続を閉じて、メモリー・リークを防止します。

  4. 複数のセッション間でWebLogic Server接続を共有するのではなく、セッションにつき1つの接続を作成することを検討します。WebLogic Serverでは、複数の接続によりロード・バランシング機能が向上します。WebLogic Serverを使用する場合、パフォーマンス・ペナルティはありませんが、一部の外部ベンダーは接続ごとにTCP/IPソケットや同様の高価なリソースを作成するため、外部ベンダーによる予想外のオーバーヘッドが生じる場合があります。

相互運用性ガイドライン

Oracle Fusion Middleware Oracle WebLogic Server APIリファレンスのJMSDestinationAvailabilityHelperには、使用可能な各種メソッドの使用法や動作に関する詳細があります(次の項で説明する相互運用性ガイドラインに関する詳細を含む)。

APIの可用性

パブリックJMS宛先可用性ヘルパーAPIは、AS11gR1PS2(WebLogic Serverバージョン10.3.3)以降のクライアントとサーバーで利用できます。

外部コンテキスト

DAヘルパーに通知リスナーを登録する際に指定するコンテキスト・プロパティは、外部ベンダーや旧バージョンのWebLogic Serverのコンテキストを含む有効なJNDIコンテキストに解決できます。

外部(WebLogic以外の)コンテキストの場合、外部JNDIベンダーのクラスは現在のクラスパス内に存在する必要があります。また、Context.INITIAL_CONTEXT_FACTORYプロパティは、外部ベンダーのJNDIコンテキスト・ファクトリのクラス名を参照する必要があります。

宛先タイプのサポート

JMSDestinationAvailabilityHelper APIは、JNDIコンテキストに登録できるどのタイプの宛先(非分散宛先、外部ベンダーの宛先など)でも機能します。ただし、使用不可の通知は、DQメンバーに対してのみ生成され、DestinationDetailの特定のフィールドはDQメンバーにのみ適用されます。使用不可の通知は、外部宛先には適用されません。

使用不可の通知

使用不可の通知は、DQタイプの宛先にのみ適用されます。

WebLogic Server 9.0以前の分散キューとの相互運用

DAヘルパーがWebLogic Server 9.0以降のDQと相互運用する場合、DQのメンバーごとに通知が生成されますが、9.0以前のバージョンと使用する場合、DQ宛先の論理JNDI名を含む単一のDestinationDetail通知のみが生成され、getDestinationType()はPHYSICALを返します。

したがって、WebLogic Server 9.0以前のDQは通常の宛先として扱われるため、冒頭で示した問題が結果的に生じます。

DestinationDetailのフィールド

一部の宛先詳細フィールドの動作は、宛先のタイプ、JMSベンダー、WebLogic JMS動作時のWebLogic Serverバージョンに基づいて変わります。Oracle Fusion Middleware Oracle WebLogic Server APIリファレンスのJMSDestinationAvailabilityHelperに関する項を参照してください。

UDQコンシューマの戦略

コンシューマ・アプリケーションは、WebLogic Serverの同じJVMで実行する場合とそうではない場合があります。これらは、それぞれサーバー側コンシューマおよびスタンドアロン・コンシューマと呼ばれます。

JMS UDQコンシューマがWebLogic Serverまたはクラスタにデプロイされる場合、アプリケーションはUDQと同じクラスタ/サーバー、または別のクラスタで実行できます。これら2つの異なるアプリケーション構成を、それぞれローカル・ケースおよびリモート・ケースと言います。

サーバー側アプリケーションでは可能なかぎりWebLogic Server MDBを使用することを強くお薦めします。

なんらかの理由によりアプリケーション・アーキテクチャでMDBを使用できないアプリケーションの場合、次のガイドラインに従ってください。

一般的な戦略

UDQに送信されるすべてのメッセージをアプリケーションで受信するには、アプリケーションがメンバーJNDI名を使用してUDQのメンバーごとに1つのコンシューマを作成する必要があります。このためには、アプリケーションがドメインのトポロジとUDQ構成を把握する必要があります。この場合、JMSDestinationAvailabilityHelperが役立ちます。

一般的な戦略では、特定のアプリケーションの各デプロイメント・インスタンスはJMSDestinationAvailabilityHelperに登録する必要があります。リスナーはメンバーの可用性に関する通知を受け取ります。

  • onDestinationsAvailable()通知を受け取ると、アプリケーションは使用可能なすべてのメンバーのDestinationDetailインスタンスのリストを取得します。その後、リストのメンバーごとにメンバーのJNDI名を使用して1つ以上のコンシューマ・インスタンスを作成する必要があります。リモート・コンシューマの場合、アプリケーションの各インスタンスは、UDQのメンバーごとにコンシューマを作成する必要があります。ローカル・コンシューマの場合、ローカルUDQメンバーでのみコンシューマを作成します。詳細は、「ローカル・サーバー・コンシューマのベスト・プラクティス」を参照してください。

  • onDestinationsUnavailable()通知を受け取ると、アプリケーションは、最後の通知以降に使用不可になるすべての宛先のDestinationDetailインスタンスのリストを取得します。その後、リストのメンバー宛先ごとに、メンバー宛先に対して以前に作成されたコンシューマを探し、そのコンシューマを閉じます。

ローカル・サーバー・コンシューマのベスト・プラクティス

アプリケーションがJMS分散宛先と同じクラスタにデプロイされる場合、可能なかぎり、UDQをホストする同じセットのサーバーにアプリケーションをデプロイする必要があります。この構成のベスト・プラクティスとして、アプリケーションはローカル・メンバーからのメッセージのみを受け取り、DestinationDetail isLocalWLSCluster()呼出しとisLocalWLSServer()呼出しを使用してローカル・メンバーを決定できます。この方法では、すべてのメッセージがローカルになり(ネットワーク呼出しでメッセージが転送されない)、すべてのメンバーがコンシューマで処理されるため、パフォーマンスが向上します。

一部の使用事例では、バランスの取れていないキューの負荷に関して、ローカル・サーバーの最適化ネットワークを節約するよりも、クラスタのすべてのJVM間でメッセージ処理を分散するメリットの方が上回ります。これは特に、メッセージのバックログがクラスタ全体で不規則に生じ、メッセージ処理に費用がかかる場合に関連します。このような使用事例では、リモート・コンシューマに対して一般的な戦略モデルを支持して最適化を回避してください。

  前
前 
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次