WebLogic Server FAQ 集
|
 |
 |
|
Q. WebLogic JMS がユニークである理由は何ですか。
A. WebLogic JMS には、数多くのユニークな機能があります。詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS の機能」を参照してください。
Q. WebLogic JMS の詳細情報はどこで参照できますか。
A. 以下のリンクを利用すれば、WebLogic JMS の詳細情報を参照できます。
Q. WebLogic JMS への C/C++ インタフェースは存在しますか。
A. はい。dev2dev の「ユーティリティ & ツール」ページで JMC C クライアントを入手できます。このページでは、jmscapi.zip ファイルをダウンロードできます。このファイルには、必要なファイル、ドキュメント、およびサンプルが含まれています。サポートされる BEA Products はありません。しかし、この API に関して質問がある場合、BEA ニュースグループ サーバの WebLogic JMS「weblogic.developer.interest.jms」ニュースグループに投稿できます。
Q. クライアントをサポートするための weblogic.jar ファイルの小型軽量バージョンはありますか。
A. はい。WebLogic Server 8.1 には、完全な J2EE アプリケーション クライアントが用意されています。WebLogic Server アプリケーション クライアントは、標準クライアントと JMS クライアントとして提供され、2 つの独立した jar ファイル (wlclient.jar と wljmsclient.jar) として WebLogic Server インストール ディレクトリの /server/lib サブディレクトリに格納されています。各 jar のサイズは、約 400KB です。
Q. WebLogic Server を起動して JMS をコンフィグレーションする方法を教えてください。
A. WebLogic Server の起動、Administration Console へのアクセス、および基本的な Weblogic JMS の実装のコンフィグレーションに関する詳細な指示については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic Server の起動と JMS のコンフィグレーション」を参照してください。
Q. WebLogic JMS セキュリティはどのようにコンフィグレーションするのですか。
A. セキュリティ ポリシーは、WebLogic リソースとユーザ、グループ、またはロールの間の関連付けを定義するときに作成します。WebLogic リソースは、セキュリティ ポリシーが割り当てられるまでは保護されません。セキュリティ ポリシーは、Administration Console を使用して任意の WebLogic JMS 送り先に割り当てることができます。
ナビゲーション ツリーを使用して、JMS 送り先 ([サービス｜JMS｜サーバ｜<server name>｜送り先]) にアクセスします。送り先を右クリックし、ポップアップ メニューから [セキュリティ ポリシーを定義] を選択します。デフォルトでは、コンソール画面には各送り先のすべての操作に対するポリシーが設定されます。また、[メソッド] フィールドを使用して、送り先の send()、receive()、および browse() 処理について個別のポリシーを設定できます。
WebLogic Server のすべてのリソースに対してセキュリティを設定する方法については、『WebLogic リソースのセキュリティ』を参照してください。
Q. WebLogic JMS 5.1 でサポートされていたデフォルト接続ファクトリはまだ使用できますか。
A. はい。それ以降のバージョンの WebLogic JMS で、5.1 の接続ファクトリを使うことに関する詳細情報については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの移植」を参照してください。
Q. JMSSession.createTopic または JMSSession.createQueue が WebLogic JMS 8.1 で送り先の作成に失敗するのはなぜですか (5.1 では正常に作成されます)。
A. この問題の詳細な説明については、バージョン 6.1 FAQ 集の「FAQ : JMS」を参照してください。
Q. キューまたはトピックのリストをプログラマティックに取得するにはどのようにすればよいですか。
A. JMS 実行時およびコンフィグレーション JMX MBean を検索するための JMS ヘルパー メソッドが用意されています。また、JMS キューおよびトピックの送り先を動的に作成および削除するためのメソッドも用意されています。詳細については、「JMS Helper メソッドの Javadoc」を参照してください。
A. 一時的な送り先を作成するすべての JMSServer にテンプレートを作成する必要があります。Temporary Template をサポートするために複数の JMSServer エントリを指定できます。これらの JMSServer の間でロード バランシングが行われ、一時的な送り先が設定されます。JMS のコンフィグレーション方法については、「WebLogic Server を起動して JMS をコンフィグレーションする方法を教えてください」を参照してください。作成されるテンプレート定義は、次のようになります。
<JMSTemplate Name="MyTemplate"/>
<JMSServer Name="MyJMSServer" TemporaryTemplate="MyTemplate" Targets="MyServer" >
テンプレート名の後に、テンプレートに任意のキュー/トピック属性を設定できます (JNDI 名とトピック マルチキャスト設定は含みません)。このテンプレートは最も外側のレベルに存在します。このため、<JMSServer> の中でネストすることはできません。
一時的な送り先は、作成する接続によってのみ消費されます。トピックを使用する場合、一時的なトピックを作成して、そのトピックにサブスクライブします。誰かにその一時的なトピックにパブリッシュしてもらうには、その人に自分のトピックを教える必要があります。その人にメッセージを送信して、一時的なトピックを JMSReplyTo フィールドに挿入できます。TemporaryTopic の作成者とサブスクライバは、同じでなければなりません。
import javax.jms.TopicSession;
TemporaryTopic myTopic = mySession.createTemporaryTopic();
TopicSubscriber = mySession.createSubscriber(myTopic);
一時的なトピックは、名前を取得せず、他の接続によってサブスクライブできません。一時的なトピックを作成すると、JMS プロバイダは javax.jms.Topic を返します。そのトピックは、他の当事者 (トピックにパブリッシュする人たち) に公開する必要があります。そのためには、JMSReplyTo フィールドにそのトピックを入れて、それらの当事者が応答できるようにします。一般に、そのトピックは他の誰もサブスクライブできません。トピックは、自分の好きなように公開できます。トピックは、シリアル化 (外部化) できます。このため、ファイルを介して RMI 呼び出しで受け渡し、JNDI 名にバインドできます。つまり、サブスクライバ サイドでトピックを作成し、他人がパブリッシュできるようにそれを公開できます。同じ接続で複数のサブスクライバを取得し、複数のセッションを使用して並行処理を取得できます。
JMS の分散送り先の使用方法については、『WebLogic JMS プログラマーズ ガイド』の「一時的な送り先の使い方」を参照してください。
Q. MBean を使用して実行時統計を印刷する方法を教えてください。
A. BEA の dev2dev Web サイトに、実行時 MBean に基づいて JMS 統計を印刷する「JMS Statistics View」プログラムがあります。また、JMS 接続、送り先、コンシューマ、およびプロデューサ MBean の実行時統計にアクセスするための JMS ヘルパー メソッドも用意されています。詳細については、「JMS Helper メソッドの Javadoc」を参照してください。
Q. 2 つの JMS サーバで同じ永続ストレージを共有できますか。
A. できません。各 JMS サーバは、それぞれ独自の永続ストレージを使用する必要があります。ファイルベースの 2 つの JMS 永続ストレージは同じディレクトリを共有できますが、それらのメッセージは別々のファイルに格納されます。この場合、ファイル名では別々のプレフィックスが使用されます。
JDBC ベースの 2 つの JMS 永続ストレージは同じデータベースを共有できますが、データベース テーブルのプレフィックス名に別々のものを使用するようにコンフィグレーションする必要があります。JDBC プレフィックス名のコンフィグレーションの詳細については、Administration Console オンライン ヘルプの「JMS JDBC ストアとプレフィックスの使用」を参照してください。同じプレフィックス名でコンフィグレーションすると、永続的メッセージは壊れるか、失われてしまいます。
Q. WebLogic JMS ではどのタイプの JDBC データベースがサポートされているのですか。
A. JMS データベースには、JDBC ドライバからアクセスできる任意のデータベースを指定できます。WebLogic JMS が検出するドライバのリストについては、Administration Console オンライン ヘルプの「JMS JDBC ストアのタスク」を参照してください。
Q. WebLogic JMS でサードパーティの JDBC ドライバを使用する方法を教えてください。
A. 使用する JDBC ドライバが、WebLogic JMS でサポートされる JDBC データベースに関する質問で述べたドライバ リストに含まれていない場合は、JMS が必要とするテーブルを手動で作成する必要があります。JDBC ストア用のデータベース テーブルを手動で作成するには、『WebLogic JMS プログラマーズ ガイド』の「JDBC データベース ユーティリティ」の手順に従ってください。
注意 : WebLogic Server は、Administration Console オンライン ヘルプの「JMS JDBC ストアのタスク」に掲載されている JDBC ドライバのサポートだけを保証します。他の JDBC ドライバはサポートされません。
JMS JDBC ストアの代わりに JMS ファイル ストアを使用する方法もあります。ファイル ストアはコンフィグレーションが簡単であり、パフォーマンスが大幅に向上することもあります。
Q. JDBC データベースで障害が発生した場合はどうなるのですか。
A. JDBC ストア テーブルの削除および再作成の手順、またはデータベース テーブルの手動作成の手順については、『WebLogic JMS プログラマーズ ガイド』の「JDBC データベース ユーティリティ」を参照してください。
config.xml ファイルの JMSServer コンフィグレーション エントリには次の形式の行が含まれている必要があります。 Store="<YOUR-STORE-NAME>"
ストアがコンフィグレーションされていない JMS が起動すると、ユーザがそのストアを必要としていないと見なされ、永続メッセージが自動的に非永続的メッセージにダウングレードされます (JMS 1.0.2 b に指定されているとおり)。
QueueSender.send(msg, deliveryMode, ...)
JMS のコンフィグレーション方法については、「WebLogic Server を起動して JMS をコンフィグレーションする方法を教えてください」を参照してください。
Q. ファイル ストアと JDBC ストアの比較はどのように行えばよいですか。
A. ファイル ストアと JDBC ストアにはいくつかの類似点と相違点があります。詳細については、Administration Console オンライン ヘルプの「JMS ストアのタスク」を参照してください。
Q. 分散送り先メンバーおよびその接続ファクトリをホストするサーバ インスタンス間でシステム クロックを同期させることは重要なのですか。
A. 非恒久サブスクライバで分散トピックを使用する場合は非常に重要です。これは、サーバ間でクロックが大きくずれると、メッセージが配信されなくなるおそれがあるためです。この現象は、以下のようにして発生します。分散トピックの接続ファクトリと分散トピック メンバーは、それぞれのローカル システム クロックを使用して、メッセージのパブリッシュ後にコンシューマが作成されたかどうかを確認します。コンシューマ作成前にトピックにパブリッシュされたメッセージは、コンシューマでは認識されません。コンシューマ作成前にメッセージをパブリッシュすると、どのトピックでも常に競合が生じます。
接続ファクトリや分散トピック メンバーをホストするサーバ インスタンス間でシステム クロックが同期していないと、この競合がより深刻になります。たとえば、アプリケーションで存続期間の短い非恒久トピック コンシューマを作成し、このコンシューマをサーバ A の接続ファクトリを使用してリスンするとします。この状況で、サーバ B の分散トピック メンバーにメッセージがパブリッシュされ、サーバ A とサーバ B のシステム クロックが同期していない (作成したトピック コンシューマの存続期間より大きなずれがある) と、このずれが原因でメッセージはコンシューマに配信されなくなります。
A. バイトとメッセージの最大値はフロー制御ではなく割り当てです。メッセージの割り当てにより、WebLogic JMS サーバがメッセージで一杯になり、メモリが不足して、予期しない結果になることが防止されます。「送信ブロック」機能が実装されていない場合、割り当てに到達すると、JMS は (ブロッキングではなく) ResourceAllocationException によってそれ以上の送信を防ぎます。割り当ては、個々の送り先またはサーバ全体に設定できます。「送信ブロック」機能の詳細については、Administration Console オンライン ヘルプの「メッセージ プロデューサのブロックによる割り当て例外の回避」を参照してください。
同様に、しきい値もフロー制御ではありません。ただし、しきい値は割り当てよりもそのアプリケーションに適しています。しきい値は、超過した場合にメッセージをコンソールに記録するための設定値に過ぎません。これにより、ユーザは対処に遅れたことを知ることができます。
WebLogic JMS 7.0 以降にはフロー制御機能があります。この機能によって、JMS サーバまたは送り先が、過負荷になりつつあるときにメッセージ プロデューサをスロー ダウンできます。特に、JMS サーバ/送り先は、指定されたバイトまたはメッセージしきい値を超えたときに、メッセージ フローを制限するようにプロデューサに指示します。詳細については、Administration Console オンライン ヘルプの「JMS サーバおよび送り先のメッセージのフロー制御」を参照してください。
注意 : 接続ファクトリに対するメッセージの最大数の設定は割り当てではありません。これは、サーバから送信されてから非同期コンシューマが見るまでの間に存在する未処理メッセージの最大数を指定します。このデフォルト値は 10 です。
Q. WebLogic JMS クラスタ化の価値は何ですか。
A. バージョン 6.x では、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS のクラスタ化のコンフィグレーション」で説明されているように、複数の接続ファクトリをコンフィグレーションし、対象を用いてそれらを複数の WebLogic Server へ割り当てることで、クラスタ内の任意のサーバから送り先まで、クラスタワイドで透過的なアクセスを確立できました。各接続ファクトリは、接続集信装置として、複数の WebLogic Server にデプロイできます。管理者は、クラスタ内のさまざまなノード上の複数の JMS サーバにユニークな名前が付けられている限り、それらの JMS サーバをコンフィグレーションして送り先を割り当てることができます。
WebLogic JMS 7.0 では、管理者は複数の送り先をクラスタ内部で単一の分散送り先セットの一部としてコンフィグレーションできます。プロデューサとコンシューマは、その分散送り先を介して送受信することができます。クラスタ内部の単一サーバの障害時には、WebLogic JMS は、分散送り先内部で利用可能なすべての物理的送り先に渡って、その負荷を分散します。詳細については、Administration Console オンライン ヘルプの「JMS 分散送り先のタスク」を参照してください。
また、WebLogic JMS は、クラスタ環境用の WebLogic Server コアに実装されている移行フレームワークを利用します。これにより、WebLogic JMS は、移行リクエストに適切に応答し、JMS サーバを正しい順序でオンラインまたはオフラインにすることができます。これには、スケジューリングされた移行だけでなく、WebLogic Server の障害への対応としての移行も含まれます。詳細については、『WebLogic JMS プログラマーズ ガイド』の「JMS サーバの移行可能対象のコンフィグレーション」を参照してください。
また、このトピックの詳細については、JMS トピック ページの「BEA WebLogic JMS Performance Guide」ホワイト ペーパー (WebLogicJMSPerformanceGuide.pdf) も参照してください。
Q. アプリケーションがどの WebLogic Server で実行されるかを制御する方法を教えてください。
A. システム管理者は、接続ファクトリのコンフィグレーション時に対象を指定することで、アプリケーションをどの WebLogic Server で実行するのかを指定できます。各接続ファクトリは、複数の WebLogic サーバにデプロイできます。接続ファクトリのコンフィグレーションまたはデフォルト接続ファクトリの使い方の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS の基礎」にある「ConnectionFactory オブジェクト」を参照してください。
A. WebLogic Server の障害からの回復手順、手動フェイルオーバの実行手順、およびプログラミングの考慮事項については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic Server の障害からの回復」を参照してください。
Q. WebLogic JMS サーバは、クローズまたは失われた接続、クラッシュ、およびその他の問題を検出して、それらから回復できますか。
A. はい、しかしその方法は、次のように Java クライアントがクラッシュしたのか、WebLogic Server がクラッシュしたのかによって異なります。
LostServerException と一緒にクライアントの javax.jms.ExceptionListener.onException(...) が呼び出される (javax.jms.JMSConnection.setExceptionListener が設定されている場合)Q. アプリケーションは、アプリケーション サーバがダウンしているかどうかをどのように知るのですか。
A. 登録できるリスナが 2 種類存在します。Sun Microsystems の JMS 仕様では、接続に問題があるかどうかを通知する Connection.setExceptionListener が定義されています。接続に問題がある場合、その接続を使用するすべてのコンシューマにも問題が発生します。接続例外を取得する理由は、接続する相手側の WebLogic サーバがダウンしているか、無応答であるか、または誰かが Mbean インタフェースを介して接続を切断したためです。
しかし、WebLogic Server JMS の場合、1 つの接続に複数のセッションが存在し、それらが複数のバックエンド サーバにアクセスする場合があります。このため WebLogic Server には、セッションに問題があるかどうかを通知する WLSession.setExceptionListener という拡張が用意されています。詳細については、「JMS WLSession の Javadoc」を参照してください。
A. J2EE は、インタフェースを標準化しています。WebLogic の RMI 仕様の実装では、T3 という独自の通信プロトコルが使用されます。Sun の RMI の参照実装では、JRMP という独自のプロトコルが使用されます。WebLogic が T3 を開発した理由は、エンタープライズクラスの分散オブジェクト システムを Java で構築するためのスケーラブルで効率的なプロトコルが必要であったためです。
T3 は WebLogic 独自のプロトコルですが、ユーザのアプリケーション コードは T3 について何も知る必要はありません。このため、これについて心配する必要はありません。「WebLogic 固有の文字列」(PROVIDER_URL、INITIAL_CONTEXT_FACTORY など) をプロパティ ファイル (またはどこか) に外部化します。これにより、コードを完全に移植可能にして、プロパティ ファイル内のそれらのみを変更するだけで、コードを取得して別の J2EE アプリケーション サーバで実行できるようになります。
注意 : リリース 8.1 では、WebLogic JMS は IIOP プロトコルもサポートしています。一般に、これは T3 プロトコルより低速です。
A. HTTP トンネリング (すべてのメッセージを HTTP に包み込んでファイアウォールを通過させること) を使用する場合、TunnelingEnabled="true" を config.xml ファイルの <Server> 定義に追加するか、Administration Console 上の該当するボックスをオンにする必要があります。次に、InitialContext を取得するときに、Context.PROVIDER_URL 用に t3://localhost:7001 ではなく http://localhost:7001 というような URL を使用します。SSL を使用して HTTP トンネリングを行う場合、https://localhost:7002 を使用します (https は HTTP トンネリングと SSL を使用します。7002 はコンフィグレーションしたセキュアなポートです)。これを行うと、パフォーマンスが低下します。このため、必要な場合にのみ (ファイアウォールを通過する必要がある場合など) トンネリングを使用してください。
Q. WebLogic JMS は SSL をサポートしていますか。
A. はい、SSL は WebLogic JMS 実装でサポートされています。SSL は、初期 JNDI コンテキストをルックアップするときに、「t3:」の代わりに「t3s:」で始まる URL を使用することによって、自動的に使用されます。
Q. 非 WebLogic JMS プロバイダと WLS を統合する方法を教えてください。
A. MQ Series、IBus MessageServer、Fiorano、および SonicMQ の統合については、Administration Console オンライン ヘルプの「リモートまたは外部 JMS プロバイダへの単純なアクセス」、および JMS トピック ページの「Using Foreign JMS Providers with WebLogic Server」ホワイト ペーパー (jmsproviders.pdf) を参照してください。
Q. 2 フェーズ トランザクションまたはグローバル トランザクションは、WebLogic JMS とどのように関連するのですか。
A. 2 フェーズ トランザクションまたはグローバル トランザクションを使用すると、複数のリソース マネージャ (EJB、データベース、JMS サーバなど) が 1 つのトランザクションに参加できます。
たとえばクライアントは、2 フェーズ トランザクションを使用して、1 つの JMS サーバ (サーバ A) のキューから別の JMS サーバ (サーバ B) のキューにメッセージを送信できます。各サーバには、固有の永続ストレージがあります。トランザクションがコミットされると、メッセージがサーバ B で表示可能になります。トランザクションがロールバックされた場合、メッセージはサーバ A のキューに戻されます。
注意 : 両方のキューが同じ JMS サーバにある場合は、1 フェーズ トランザクションを使用します。
Q. WebLogic JMS 処理がユーザ トランザクションの一部にならない (トランザクション内で呼び出されるが、適切にロールバックされない) のはなぜでしょうか。トランザクションの問題を追跡するにはどのようにすればよいでしょうか。
A. 通常、この問題は、設計により外部のグローバルなトランザクションを無視するトランザクション セッションを明示的に使用することによって発生します (JMS 仕様の要件)。トランザクション JMS セッションは、常に独自の内部トランザクションを持ちます。これは、呼び出し側が持っているトランザクション コンテキストによって影響されません。
また、この問題は、「XAConnectionFactoryEnabled」が false に設定されている接続ファクトリを使用することによっても発生します。
import javax.transaction.*
import weblogic.transaction.*;
また、以下の行を追加します (各処理の直前および直後など)。
Transaction tran = TxHelper.getTransaction();
System.out.println(tran);
System.out.println(TxHelper.status2String(tran.getStatus()));
weblogic.jms.ConnectionFactory は、ユーザ トランザクションを無効化します。このため、ユーザ トランザクションが必要な場合には使用しないでください。
javax.jms.QueueConnectionFactory および javax.jms.TopicConnectionFactory はユーザ トランザクションを有効化します。
-Dweblogic.Debug.DebugJMSXA=true
Q. WebLogic JMS 操作がトランザクション コンテキストの一部として実行されるのはどのような場合ですか。
A. WebLogic JMS がサーバの内部で使用される場合、パラメータの設定に応じて、JMS セッションが JTA トランザクションに自動的に登録されます。8.1 より前のリリースでは、WebLogic JMS セッションは、次の 2 つの条件のいずれかを満たした場合に JTA トランザクションに自動登録されました。
WebLogic Server 8.1 では、設定する必要があるのは XAConnectionFactoryEnabled フラグだけです。ただし、古いフラグも下位互換性のためにサポートされています。
WebLogic JMS 接続ファクトリが resource-reference として EJB、サーブレット、または JSP の内部に登録され、java:comp/env JNDI ツリーからルックアップされる場合、EJB コンテナはトランザクション登録の適切なフラグが設定されているかどうかをチェックします。WebLogic JMS 接続ファクトリが自動トランザクション登録をサポートしていない場合、EJB コンテナは JMS セッションがトランザクション コンテキストの内部で使用されるときに例外を送出します。しかし、resource-reference なしで使用する場合 (java:comp/env を使用せずに JMS 接続ファクトリを直接ルックアップする EJB の場合など)、チェックは行われません。JMS セッションが JTA トランザクションの外部で使用される場合、トランザクション登録は行われません。
デフォルト接続ファクトリ weblogic.jms.ConnectionFactory は、自動トランザクション登録をサポートしていません。この機能が必要な場合、weblogic.jms.XAConnectionFactory ファクトリを使用する必要があります。従来の接続ファクトリ javax.jms.QueueConnectionFactory と javax.jms.TopicConnectionFactory も自動トランザクション登録をサポートしています。
詳細については、『WebLogic JMS プログラマーズ ガイド』の「EJB とサーブレットでの JMS の使い方」を参照してください。
Q. アプリケーションがトランザクションの結果に関係なく JMS 処理を正常に実行する方法を教えてください。
A. この処理を実行するには、トランザクションをサスペンドする必要があります。その方法は、JMS を使用するコンテキストによって異なります。
import javax.transaction.TransactionManager;
TransactionManager tranManager= TxHelper.getTransactionManager();
Transaction saveTx = null;
try {
saveTx = tranManager.suspend();
... do JMS work, it will not participate in transaction
} finally {
// 中断されたトランザクションは常に再開する必要がある
if (saveTx != null) tranManager.resume(saveTx);
}
javax.jms.QueueConnectionFactory または javax.jms.TopicConnectionFactory ファクトリを使用する場合、または独自のファクトリを定義して UserTransactionsEnabled フラグを True に設定した場合、JMS セッションは外部のトランザクションに参加します (外部トランザクションが存在し、JMS セッションがトランザクション セッションではない場合)。Q. トランザクション内で acknowledge() が呼び出された場合、何が起こりますか。
A. Sun Microsystems の JMS 仕様により、トランザクションの中では acknowledgeMode は無視されます。このため、トランザクションの中で acknowledge() メソッドが呼び出された場合、それは無視されます。
Q. JMS を JDBC 呼び出しと一緒に使用するときに JDBC XA エラーが発生するのはなぜですか。
A. あるトランザクションに 2 つのリソース (JMS やデータベースなど) が参加するときには、そのトランザクションは 2 フェーズとなります。使用しているデータベース ドライバが XA 互換ではないため、通常 2 フェーズ トランザクションには参加できません。これを解決するには、XA 互換ドライバを使用するか、または JDBCTxDataSource 値をコンフィグレーションして enableTwoPhaseCommit を true に設定します。後者の場合、ヒューリスティック エラーが発生する場合があるので注意してください。JMS を現在のトランザクションに参加させたくない場合、「アプリケーションがトランザクションの結果に関係なく JMS 処理を正常に実行する方法を教えてください。」を参照してください。
Q. 他の作業に使用しているのと同じデータベース上に WebLogic JMS JDBC ストアがある場合、1 フェーズ コミットを使用できますか。
A. 使用できません。WebLogic JMS は自身のリソース マネージャです。つまり、JMS 自体が XAResource を実装し、メッセージがデータベースに格納されている場合でも、データベースに依存せずにトランザクションを処理します。このため、JMS とデータベースを使用するときには、そのデータベースが JMS メッセージが格納されているデータベースと同じである場合でも、常に 2 フェーズ コミットになります。
JMS キューと同じサーバ上にデータベース作業に使用する接続プールが存在していれば、パフォーマンスが向上します。トランザクションは依然として 2 フェーズですが、より小さいオーバーヘッドで処理されるからです。また、JMS JDBC ストアではなく JMS ファイル ストアを使用することによっても、パフォーマンスが向上する場合があります。
Q. XAResource と WLS を統合して、別のリソース マネージャで JTA トランザクションを取得する方法を教えてください。
A. ほとんどの場合、これは WebLogic JMS によって自動的に行われます。詳細については、JMS トピック ページの「Using foreign JMS providers with WebLogic Server」ホワイト ペーパー (jmsproviders.pdf) を参照してください。
Q. XA ドライバまたは TX データ ソースを使用して WebLogic JMS を起動するときに例外が発生するのはなぜですか。
A. JMS で TX データ ソースを使用することはできません。JMS は、非 XA リソース ドライバを使用する JDBC 接続プールを使用する必要があります (XA ドライバまたは JTS ドライバは使用できません)。enableTwoPhaseCommit オプションは設定しないでください。JMS は JDBC ドライバの上で XA をサポートします。
A. はい。WebLogic Server 6.1 以降は、XAConnection、XAConnectionFactory、XAQueueConnection、XAQueueConnectionFactory、XAQueueSession、XASession、XATopicConnection、XATopicConnectionFactory、および XATopicSession メソッドを完全に実装しています。これらのメソッドは、Sun Microsystems の JMS 仕様ではオプションとして定義されています。XAResource インタフェースの一部ではありません。
注意 : これらのインタフェースは必要ありません。WebLogic JMS は WebLogic トランザクション モニタに自身を自動的に登録します。
Q. トランザクション内で送信したメッセージに対する応答を受信できないのはなぜですか。
A. コンテナ管理トランザクションを使用している場合、EJB から送信された元のメッセージは送信されません。以下に、何が起こるかを示します。
これを解決するには、Bean 管理のトランザクションを使用するか、または送信および受信を 2 つの独立したメソッドに分割します。
Q. ロールバックまたは回復されるメッセージはどのようになるのですか。
A. メッセージがロールバックまたは回復されるときの処理については、『WebLogic JMS プログラマーズ ガイド』の「ロールバック、回復、再配信、または期限切れメッセージの管理」を参照してください。
Q. メッセージを保留にしておいて、後で確認応答することは可能ですか。
A. これを行うためのプリミティブは存在しません。以下に、可能な解決策を 2 つ示します。
while (true) {
Create a session, subscribe to one message on durable subscription
Save session reference in memory
To acknowledge the message, find the session reference and call
acknowledge() on it.
}
もう 1 つは、トランザクションを使用して、次のように作業をサスペンドすることです。
start transaction
while(true) {
message = receive();
if (message is one that I can handle)
process the message
commit
} else {
suspend transaction
put transaction aside with message
start transaction
}
}
resume user transaction
commit
resume user transaction
rollback
サスペンドするたびに、トランザクションをメッセージとともにスタックまたはリストに置いて、後で処理またはロールバックできるようにする必要があります。この解決策は、未処理トランザクションが大量に蓄積する可能性があるため、高いオーバーヘッドとなります。トランザクションはタイムアウトを持っており、自身でロールバックする場合があるため、メッセージを (異なるトランザクションで) 再び取得する可能性があることに注意してください。また、未処理にしておくトランザクションの数には実際的な制限があることにも注意してください。デフォルトの制限は約 10000 です。最終的には、スタック/リストに戻ってトランザクションをコミット/ロールバックします。トランザクション参照 (javax.transaction.Transaction) はシリアル化できないことに注意してください。
Q. ソートされたキューまたはトピックはどのように使用するのですか。
A. 送り先のデフォルトのソート順は FIFO (先入れ先出し) です。このため、特定の送り先のソート順を定義するには、送り先キーを使用します。送り先キーとしては、メッセージ ヘッダまたはプロパティ フィールドを使用できます。有効なメッセージ ヘッダおよびプロパティ フィールドのリストについては、『WebLogic JMS プログラマーズ ガイド』の「Message オブジェクト」を参照してください。
送り先は、送り先キーに基づいて昇順または降順でソートされます。JMSMessageID メッセージ ヘッダ フィールドに対して送り先キーが ascending として定義されている場合、送り先のソート順は FIFO となり、descending として定義されている場合は LIFO (後入れ先出し) となります。JMSMessageID ヘッダ フィールドに対する送り先キーを指定する場合、そのキーはキー リストに定義される最後のキーでなければなりません。複数の送り先キーを定義して送り先をソートできます。
送り先キーを作成するには、Administration Console の [送り先キー] ノードを使用します。詳細については、Administration Console オンライン ヘルプの「送り先キーのタスク」を参照してください。
Q. 送信されるメッセージに追いつかないリスナをどのように処理すればよいでしょうか。
A. メッセージ リスナ用に非同期パイプラインを使用してパフォーマンスを向上させることを検討してください。詳細については、『WebLogic JMS プログラマーズ ガイド』の「非同期メッセージ パイプライン」を参照してください。
Q. スレッド ダンプを取得して問題を追跡する方法を教えてください。
WL_HOME\server\bin で setEnv スクリプトを実行後)。java weblogic.Admin -url t3://localhost:7001 THREAD_DUMP
〔Ctrl〕+〔Break〕を入力します。 kill -3 を使用してサーバにシグナルを送ります。 A. はい、恒久サブスクライバではユニークなクライアント識別子が必要です。接続ファクトリのクライアント ID 属性を使用する、またはアプリケーションをプログラミングして (setClientID() を呼び出して) その接続にクライアント ID を設定することによって恒久サブスクライバをコンフィグレーションする方法については、『WebLogic JMS プログラマーズ ガイド』の「恒久サブスクリプションの設定」を参照してください。
Q. キューを管理して特定のメッセージを参照および削除する方法を教えてください。
A. QueueBrowser を使用するプログラムを記述します。次に、以下の例のとおり、QueueReceiver をセレクタとメッセージ識別子と一緒に使用して特定のメッセージを削除します。
String selector = "JMSMessageID ='" + message.getMessageID() + "'";
キュー ブラウザは、キューの実際のビューではないことに注意してください。これはスナップショットです。
Q. メッセージはどのような順序でコンシューマに配信されるのですか。
A. プロデューサとコンシューマ間の順序は、配信モードと同じようにソート順序で管理され、ロールバックまたは回復が存在しない場合はセレクタによって管理されます。複数のプロデューサが単独のコンシューマに送信するか、または複数のコンシューマが複数のプロデューサから受信する場合、順序の保証はまったくありません。
順序は、一般にプロデューサとコンシューマの間で管理されます。ただし、非永続メッセージは、ソート順序がより高い (優先度がより高い、など) 永続メッセージより優先し、他より前に移動できます。また、回復またはロールバックは受信済みのメッセージをキュー/トピックに戻します。これにより、順序が影響を受けます。
大部分のメッセージング システム (WebLogic JMS を含む) は、プロデューサと送り先間、および送り先とコンシューマ間の順序を管理します。このため、いったんメッセージが送り先に到着したら、順序は変更されません。
最後に、WebLogic JMS でサポートされる非同期パイプラインも順序に影響を与えます。デフォルトでは、サーバから非同期クライアントに送信される未処理メッセージが最大 10 通も存在する可能性があります。非同期コンシューマが「捕まえられた」場合、これらのメッセージはソートされません。パイプラインでは送り先のソートは行われません。送り先が優先度でソートされ、到着する新しいメッセージの優先度がパイプラインにすでに存在するメッセージより高い場合、新規メッセージはパイプライン内を飛び越えることはなく、送り先の最初に置かれます。パイプラインのサイズはコンフィグレーション可能です。使用する接続ファクトリの MessagesMaximum 設定を参照してください。真の優先度ソートを行いたい場合、接続ファクトリの最大メッセージ数を 1 に変更してください。詳細については、『WebLogic JMS プログラマーズ ガイド』の「非同期メッセージ パイプライン」を参照してください。
Q. ロールバックおよび回復時でもメッセージの順序を保証するにはどのようにすればよいでしょうか。
A. ロールバックおよび回復が実行された場合でも、WebLogic JMS 8.1 のメッセージの順序は、キューまたはトピック サブスクリプションの単独のコンシューマに対して保持されます。詳細については、『WebLogic JMS プログラマーズ ガイド』の「メッセージの再配信の順序付け」を参照してください。
Q. 複数のキュー レシーバが同じキューをリスンすることは可能ですか。
A. はい。ただし、JMS 仕様ではこうした動作は定義されていません。
Q. 1 つのアプリケーションがあるキューにリスナとして 1 つのオブジェクトを持っており、他のアプリケーションがそのキューのメッセージをリスンできるようにキューを作成する方法はありますか。
A. いいえ。その代わりとして、1 つの恒久サブスクリプションを持つトピックを作成できます。恒久サブスクリプションには、1 つのコンシューマだけを関連付けることができるからです。この欠点は、セレクタがキューのときのようには機能しなくなることです。Sun Microsystems の JMS 仕様によると、恒久サブスクリプションに対するセレクタを変更すると、サブスクリプションが「リセット」されます。この結果、そのサブスクリプションに現在存在するすべてのメッセージが削除されます。
注意 : クライアント ID が設定されている接続ファクトリをコンフィグレーションする場合、これによって接続ファクトリは 1 つのクライアントに制限され、目的が満たされます。
Q. javax.jms.Message.setJMSPriority、DeliveryMode、Destination、TimeStamp、または Expiration を使用するときに設定値が機能しないのはなぜですか。
A. これらのメソッドは、ベンダ専用です。メッセージの値は、各 send/publish メソッドにオーバーライドされます。これらの値を設定するには、MessageProducer、QueueSender、または TopicPublisher の対応メソッド (setJMSPriority、setDeliveryMode、setTimeToLive など) を使用する必要があります。これらの値がオプションのテンプレート コンフィグレーションのオーバーライド値によってオーバーライドされていないかどうかをチェックしてください。
Q. WebLogic JMS クライアントをマルチスレッド化する場合は、どのような注意が必要ですか。
A. マルチスレッドのルールについては、JMS 仕様の 2.8 節に記載されています。セッションの使い方に関しては 4.4.6 節、複数のセッションに関しては 4.4.9 節、そして並行メッセージ配信に関しては 4.4.17 節で追加の言語と共に説明されています。nutshell では、JMS セッションがシングル スレッドであることが示されています。したがって、複数のスレッドがセッションあるいはコンシューマまたはプロデューサのどれかに同時にアクセスする場合、動作は保証されません。さらに、複数の非同期コンシューマがセッションに存在する場合、メッセージは並列的ではなく連続的にそれらに配信されます。
JMS で複数のスレッドを利用するには、複数のセッションを使用します。たとえば、並列な同期受信リクエストを可能にするには、セッションごとに 1 つのコンシューマだけがアクティブになるようにアプリケーションを設計し、複数のセッションを使用します。
Q. 複数のトピックをサブスクライブするにはアプリケーションをどのように設定すればよいですか。
A. N 個のトピックをリスンする場合、N 個のサブスクライバと N 個のセッションを使用すると N 個の同時実行スレッドまで同時実行性が提供されます (それだけ多くのスレッドを使用する場合)。N 個のサブスクライバと 1 個のセッションでは、そのセッションを介してすべてのサブスクリプションがシリアライズされます。負荷が重い場合、追加のスレッドがなければ追いつくことができません。また、CLIENT_ACKNOWLEDGE を使用する場合、N 個のセッションによって、個々に回復可能な N 個の独立したメッセージ ストリームが与えられます。1 個のセッションだけがそれらのストリームを横切ると、制御が低下します。
バージョン 6.x 以降では、サーバサイドの WebLogic JMS は、存在するクライアント セッションの数に関係なく、小さい固定数のスレッドを有効に使用します。
Q. receive() 呼び出しのブロックおよび非同期の receive() 呼び出しはどのように利用するのですか。
A. 同期 receive() メソッドは、メッセージが生成されるまで、タイムアウト値に達するまで (指定されている場合)、またはアプリケーションが閉じるまでブロックされます。サーバサイドでの receive() 呼び出しのブロックはできる限り行わないでください。同期 receive() 呼び出しは、その呼び出しがブロックされている全期間にわたってリソースを消費するからです。
メソッドが非同期で受信される場合、メッセージが生成されたときにのみメッセージ リスナを使用してアプリケーションに通知されます。そのため、メッセージを待つことでリソースが消費されることがありません。
Q. receive() 呼び出しをブロックするときに注意することは何ですか。
A. アプリケーションの設計上、メッセージを同期的に受信する必要がある場合、以下のメソッドのいずれかを使用することをお勧めします (望ましい順に挙げてあります)。
receive() メソッドに渡し、サーバからの応答を待つスレッドの浪費を避けるためにアプリケーションによって許可される最小値 (0 より大きい値) に設定します。 receiveNoWait() メソッドを使用します。このメソッドは次のメッセージを返すか、現在取得できるメッセージが存在しない場合は NULL を返します。この場合、呼び出しはブロックされません。サーブレットは、wait() を呼び出さずに、リクエストに戻るか、リクエストを再スケジューリングする方法を提供します。 注意 : ビジー状態のサーバでデッドロックを引き起こすことがあるため、このオプションの使用は最小限にします。
Q. NO_ACKNOWLEDGE 確認応答モードの目的は何ですか。
A. NO_ACKNOWLEDGE 確認応答モードは、受信したメッセージで確認応答の必要がないことを示します。これでパフォーマンスは向上しますが、メッセージが失われるおそれがあります。このモードは、セッションの確認応答で提供されるサービスの質を必要とせず、それに関連するオーバーヘッドを避ける必要があるアプリケーションで使用します。
NO_ACKNOWLEDGE セッションに送信されたメッセージは、サーバから即座に削除されます。このモードで受信されたメッセージは回復されないので、メッセージを配信する最初の試行が失敗した場合はメッセージが失われたり、重複メッセージが配信されたりします。
注意 : アプリケーションで、失われたメッセージや重複メッセージを処理できない場合は、このモードは使用しないでください。重複メッセージは、メッセージを配信する最初の試行が失敗した場合に送信されます。
また、この確認応答モードは永続的なメッセージングでは使用しないでください。永続的なメッセージングにとっては、サービスの質が低すぎる可能性があります。
Q. マルチキャスト サブスクライバを使用するのはどのような場合ですか。
A. マルチキャストを使用することによって、後でメッセージをマルチキャスト サブスクライバに転送する、指定したホストのグループにメッセージを配信できます。マルチキャストには、次のような利点があります。
注意 : マルチキャストは、Pub/sub メッセージング モデルのみでサポートされています。
マルチキャストを使用すると便利な例としては、株価表示があります。最新の株価を入手する場合に重要になるのは、信頼性よりもタイムリーな配信です。全部または一部の内容が配信されなくても、リアルタイムの株価情報にアクセスするときに、クライアントは簡単に情報の再送信を要求できます。クライアントでは情報の回復は必要とされません。回復された情報が再配信される頃には、その情報は古くて価値のないものになっているからです。
マルチキャストでは、ホスト グループの全メンバーに対するメッセージの配信は保証されません。確実な配信と回復が必要なメッセージについては、マルチキャストを使用しないでください。
Q. サーバ セッション プールと接続コンシューマは、どのような場合に使用するのですか。
A. WebLogic JMS には、サーバ セッションのサーバ管理プールを定義するためのオプションの JMS 機能が実装されています。しかし、セッション プールは現在ほとんど使用されていません。理由は、J2EE 仕様の必須の部分ではないこと、JTA ユーザ トランザクションをサポートしていないこと、そして大部分がメッセージ駆動型 Bean (MDB) に取って代わられたことです。MDB の方が簡単で管理しやすく、高機能です。
このトピックの詳細については、JMS トピック ページの「BEA WebLogic JMS Performance Guide」ホワイト ペーパー (WebLogicJMSPerformanceGuide.pdf) の「MDBs vs. ServerSessionPools」を参照してください。
Q. onMessage() メソッド呼び出し内で close() メソッドを発行するにはどのようにすればよいですか、また、close() メソッドのセマンティクスは何ですか。
A. onMessage() メソッド呼び出し内で close() メソッドを発行する場合、システム管理者は接続ファクトリをコンフィグレーションするときに [メッセージの短縮を許可] チェック ボックスを選択しなければなりません。詳細については、Administration Console オンライン ヘルプの「JMS 接続ファクトリのタスク」を参照してください。このチェック ボックスが選択されていない状態で、onMessage() メソッド呼び出し内で close() メソッドを発行すると、その呼び出しはハングします。
セッションまたは接続の close() メソッドは、次の手順を実行して系統的にシャットダウンを行います。
close() メソッドを呼び出すメッセージ リスナは除きます。 接続をクローズすると、関連付けられているすべてのオブジェクトがクローズされます。受信メッセージの acknowledge() メソッドを除いて、接続で作成または受信されたメッセージ オブジェクトは引き続き使用できます。閉じた接続をクローズしても影響はありません。
注意 : クローズされた接続のセッションから受信したメッセージを確認応答しようとすると、IllegalStateException が送出されます。
セッションをクローズすると、関連付けられているすべてのプロデューサとコンシューマもクローズされます。
各オブジェクトについての close() メソッドの影響については、該当する javax.jms javadoc を参照してください。
Q. XML メッセージをパブリッシュするにはどのようにすればよいですか。
Q. WebLogic JMS をアプレットで使用するにはどのようにすればよいですか。
A. 詳しい手順およびその例については、JMS トピック ページの「Using BEA WebLogic JMS with Applets」を参照してください。
Q. 起動クラスを使用して WebLogic JMS オブジェクトを初期化し、後でそれを参照するにはどのようにすればよいですか。
A. このトピックについては、「news://newsgroups.bea.com/3ad0d7f3@newsgroups.bea.com」を参照してください。サンプル コードでは、シャットダウン時に正しくクリーンアップが実行されません。以下のような処理を行う停止クラスを使用できます。
JMSobject WLSobject = null;
try {
WLSobject = JMSStartUp.getJMSobject();
WLSobject.JMSCleanup();
} catch(Exception e) {}
サーブレットは、初期化とクリーンアップの両方を行うための優れたソリューションを提供します。詳細については、「アプリケーション サーバ内でスレッドの作成や初期化の実行などを行うための標準的な方法を教えてください。」を参照してください。
Q. メッセージ リスナ内からのメッセージの送受信は可能ですか。
A. はい。メッセージ リスナ内から任意のキューまたはトピックに対して送受信を行うことができます。
MDB ではない場合、onMessage() を含む同じ Connection または Session を使用してこれを行うことができます。メッセージ リスナを作成する場合、コンストラクタにセッションを渡します。次に、onMessage メソッドにアクセスし、onMessage メソッド内から非同期ではなく同期呼び出しを行うことができます。別の onMessage() にサービスを提供する Session を使用しないでください。Session および Sessions はマルチスレッドをサポートしないからです。
しかし、このテクニックを MDB の外部で使用する場合、MessageListener によるメッセージの受信、および新規メッセージの送信が同じトランザクションの一部として行われることを保証する方法はありません。このため、重複やメッセージの喪失が発生する場合があります。次に例を示します。
publish() の後に確認応答を呼び出し、確認応答が何らかの理由 (ネットワークまたはサーバの障害) で失敗した場合、メッセージが再び表示され、パブリッシュが 2 回行われます (セマンティクスが重複する可能性があります)。連続番号を追跡して重複を削除することもできますが、簡単ではありません。 publish() の前に確認応答を呼び出した場合、セマンティクスを 1 回だけ取得します。publish() が失敗すると、メッセージがサーバに到着する前か後のどちらで障害が発生したのかが分かりません。 onMessage を使用してトランザクション セマンティクスが 1 回だけ必要な場合は、トランザクション MDB を使用する必要があります。この場合、トランザクション MDB の onMessage() メソッドはトランザクションを起動し、そのトランザクションで受信した WebLogic JMS メッセージを組み込みます。次に、新しいメッセージの send または publish がメッセージの受信として同じトランザクションの一部となることを保証する必要があります。
WebLogic Server 8.1 では、MDB に対して定義した resource-reference から取得する接続ファクトリを使用することでこれを保証できます。詳細については、『WebLogic JMS プログラマーズ ガイド』の「EJB とサーブレットでの JMS の使い方」を参照してください。また、resource-reference を使用すると、JMS Connection、Session、および MessageProducer オブジェクトが自動的にプールされ、WebLogic JMS を使用するか、別の JMS プロバイダを使用するかに関係なくトランザクションの登録が自動的に行われるようになります (JMS プロバイダが XA をサポートしている場合)。
旧バージョンでは、WebLogic JMS は UserTransactionsEnabled または XAServerEnabled フラグが接続ファクトリに設定されている場合に自身を現在のトランザクションに自動登録しました。しかし、8.1 より前のリリースでは、JMS オブジェクトはプールされず、外部の JMS プロバイダはトランザクションに自動登録されません。これらの旧バージョンでは、JMS オブジェクトをキャッシュする必要があります。詳細については、「プロデューサ プールはどのように作成するのですか。」を参照してください。
A. 詳細については、『WebLogic JMS プログラマーズ ガイド』の「EJB とサーブレットでの JMS の使い方」を参照してください。詳しいコード サンプルについては、JMS トピック ページの「BEA WebLogic JMS Performance Guide」ホワイト ペーパー (WebLogicJMSPerformanceGuide.pdf) の「Appendix A: Producer Pool Example」を参照してください。
ロールバックされたメッセージは、トランザクションが実際にロールバックするまで保留状態に置かれます。ロールバックを何度も行っても、重複カウントは発生せず、例外も発生しません。トランザクションが rollbackOnly として設定され、続いて実際のロールバックが発生します。
Total は、サーバが最後に起動したときからの合計を表します。バイト数は、メッセージのペイロードのみを考慮します。これには、プロパティと本文が含まれますが、ヘッダは含まれません。
Q. ejb-jar.xml のメッセージ選択で「より小さい」または「より大きい」を使用する方法を教えてください。
A. セレクタを CDATA セクションで囲みます。これにより、XML パーサは「より小さい」または「より大きい」をタグとして認識しなくなります。
<jms-message-selector>
<![CDATA[ JMSXAppID <> 'user' ]]>
</jms-message-selector>
Q. WebLogic JMS API で別のベンダの送り先を使用できますか。
A. WebLogic Server JMS は、外部の送り先を処理する方法を知りません。この問題については Sun と協議してきましたが、Sun 仕様での送り先の定義は、ベンダがそのレベルで相互運用できるほど明確ではありません。JavaSoft 側は、受信/送信が正常に機能するように外部送り先を処理するには、この仕様は十分でないことを認めています。WebLogic JMS の場合、外部送り先を使用して setJMSdestination を実行した場合 (これを設定するのはプロバイダだけなので、実際には行わないでください)、それは無視されます (NULL に設定される)。同様に、外部送り先用に setJMSReplyTo を実行した場合、WebLogic JMS はそれを無視します (NULL に設定する)。
Q. アプリケーション サーバ内でスレッドの作成や初期化の実行などを行うための標準的な方法を教えてください。
A. 通常、スレッドを直接作成しないでください。正常に機能しない場合があります。ユーザが作成したスレッドは、WebLogic Server が独自の実行スレッド、関連付けられるトランザクション コンテキスト、または環境 (適切なクラス ローダなど) の作成時にあらかじめ設定するスレッドローカル変数の一部を備えていません。WebLogic 独自の方法でこれを行うには、起動クラスまたは WebLogic Time サービスを使用します。これを行うための移植可能な方法は、起動時にロードされるサーブレットを定義し、init() メソッドで初期化を行い、destroy() メソッドでクリーンアップを行うことです。サーブレット自体は何も行いません。このアプローチを使用すると、サーバを再起動せずにアンデプロイ/再デプロイを行うことができます (毎回の適切なクリーンアップ/初期化を含む)。また、サーバを起動せずに依存クラスをより動的に管理できるようになります。
Q. トピック A.B と 2 番目のトピック A.B.C に名前を付けたときに JNDI の問題が発生するのはなぜですか。
A. これは JNDI の実装の問題です。JNDI はドット (.) を使用してディレクトリに似た構造を構築します。ある要素がノードとツリー内のリーフを兼ねることはできません。この例では、B は A のリーフとして使用されますが、次にリーフ C のノードとして使用されます。
A. XPATH 構文を WebLogic JMS で使用する手順およびサンプルについては、『WebLogic JMS プログラマーズ ガイド』の「XML セレクタ メソッドを使用した XML メッセージ セレクタの定義」を参照してください。
Q. WebLogic JMS を使用して要求/応答を処理する方法を教えてください。
A. JMS で要求/応答を処理する方法はいくつかあります。
// 応答用の一時キューを作成する
qrequestor = new QueueRequestor(qsession, queue);
TextMessage msg = qsession.createTextMessage();
TextMessage reply = (TextMessage) qrequestor.request(msg);
WebLogicJMSPerformanceGuide.pdf) の「Using a Request/Response Design」を参照してください。Q. キューまたはトピック接続が開始されてから新しいセッションとサブスクライバをそれらに追加することはできますか。
A. はい。ただし、1 つ注意が必要です。セッションがアクティブな非同期コンシューマを持つ場合、そのセッションに新しいサブスクライバ/コンシューマを追加できません。Sun Microsystems の JMS 仕様により、セッションは単一スレッドでのみアクセスされる必要があります。これを行う必要がある場合、新しい Session を作成し、そのセッションにそれを追加します。
開始された接続にレシーバを追加できます。しかし、レシーバ自体は非同期ではありません。非同期にするには、リスナが必要となります。最初のレシーバの作成は、常に安全です。その最初のレシーバに対してリスナを追加する場合、同じセッションに参加する将来のレシーバについて心配する必要があります。新しいセッション、およびそのセッションの最初のレシーバは、何の心配もなく作成できます。
セッションに 2 番目のレシーバを作成する場合、最初のレシーバが MessageListener を持っているときには、そのセッションに他の実行スレッドが存在しないことを確認する必要があります。そのためには、接続を停止するか、または最初のレシーバの onMessage ルーチンから 2 番目のレシーバを実際に作成します。
Q. プロデューサがコンシューマより高速であるため java.lang.OutOfMemoryError を受け取った場合、何を行えばよいですか。
A. 割り当てを使用すると、この状況を解決できます。送信者は ResourceAllocationExceptions を受け取り、サーバは引き続き正常に動作します。リリース 8.1 以降では、ResourceAllocationExceptions を受信する代わりに、スペースが空くのを待たないように送信者をコンフィグレーションできます。詳細については、Administration Console オンライン ヘルプの「メッセージ プロデューサのブロックによる割り当て例外の回避」を参照してください。
また、メッセージ ページング機能を使用することもできます。この機能を使用すると、メッセージ負荷が指定のしきい値に達したときにメッセージを仮想メモリから専用のページング ストアにスワップすることによってメモリを節約できます。JMS メッセージ ページングでは永続メッセージのデータもメモリにキャッシュされるため、永続メッセージおよび非永続メッセージの両方についてメモリを節約できます。詳細については、Administration Console オンライン ヘルプの「メッセージのページングによるメモリの解放」を参照してください。
A. 接続は、単一の物理的な接続 (TCP/IP リンク) であると考えることができます。セッションは、順序付けられた一連のメッセージを作成および消費するための手段です。接続の作成は、一般に高くつきます。セッションの作成は、それほど高くありません。一般に、1 つの接続を使用し、すべてのスレッドを共有します。各スレッドは、独自のセッションを持ちます。複数のスレッド グループがあり、特定のスレッド グループのリソースを起動/停止/クローズする必要がある場合は、グループごとに 1 つの接続を使用するのが適切です。グループは、1 つのスレッドを持つことができます。
Q. setMessageSelect(String) を使用して、TopicConsumer の既存のセレクタを動的に変更する方法はありますか。
A. いいえ。いったんコンシューマをインスタンス化したら、セレクタはコンシューマが作成される時点で固定されます。セレクタを変更することは、現在のコンシューマを削除し、関連付けられているすべてのメッセージを削除して新しいコンシューマを作成することとほぼ同じです。
Q. 非同期メッセージのデッドロックを回避するにはどうすればよいですか。
A. JMS 仕様の制限により、セッションの close() メソッドがユーザ同期ブロックの内部に存在する場合、非同期メッセージがデッドロックされる場合があります。これを解決するには、close() メソッドをユーザ同期ブロックの外部に移動する必要があります。次に例を示します。
public class CloseTest() {
private void xxx() {
synchronized (this) {
create connection/session/consumer
initialize and set a listener for this consumer;
wait();
connection.close();
}
}
private void onMessage(Message message) {
synchronized (this) {
notify();
}
}
}
connection.close() メソッドがクローズされる前に、JMSProvider によって別のメッセージが onMessage ルーチンに配信される場合があります。main() メソッド スレッドは、CloseTest メソッドのモニタ ロックを保有します。CloseTest クラスの onMessage() メソッドが実行される前に、JMS は INLISTENER を JMSSession のセッションのステートとして設定します (JMS 仕様では、close() メソッドは onMessage ルーチンを待つ必要があります)。このため、main() メソッド スレッドは onMessage ルーチンが完了するのを待つことができます。
onMessage ルーチンがモニタ ロックを取得しようとすると、このルーチンはブロックして main() メソッド スレッドがあきらめるのを待ち、main() メソッド スレッドは onMessage が完了するのを待ちます。
また、コンシューマの close() メソッドが onMessage ルーチンから実行され、config.xml ファイルの allowCloseInOnMessage 属性が false に設定されると、JMS もブロックします。
A. メッセージ駆動型 Bean は、JMS のキューやトピックからメッセージを受信した結果として EJB コンテナによって呼び出されるステートレスなコンポーネントです。呼び出されたメッセージ駆動型 Bean は、メッセージの内容に基づいてビジネス ロジックを実行します。これにより、JMS コンフィグレーションや再接続といった作業から開放されます。
メッセージ駆動型 Bean モデルを使用すると、EJB 開発者は慣れ親しんだフレームワークやツールを利用できると同時に、コンテナの提供する追加サポートへのアクセスを提供することもできます。メッセージ駆動型 Bean モデルの目的は、JMS メッセージを処理するために非同期で呼び出される EJB の開発を、他の JMS MessageListener で同じ機能を開発することと同じくらい容易にすることです。
標準の JMS MessageListener の代わりにメッセージ駆動型 Bean を使用する主な利点の 1 つは、JTA トランザクションを自動的に開始することができ、受信メッセージがそのトランザクションの一部になることです。この場合、他の処理が同じ JTA トランザクション (データベース処理など) に参加できます。これは、非同期コンシューマからのメッセージと別の JTA 処理を同じトランザクションに参加させる唯一の方法です。
メッセージ駆動型 Bean の詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「メッセージ駆動型 Bean」を参照してください。
Q. メッセージ駆動型 Bean の同時実行性はどのように機能するのですか。
A. キューの場合、MDB がデプロイされる各サーバ インスタンス上で複数の JMS セッションが作成されます。作成されるセッションの数は、MDB のデプロイメント記述子の max-beans-in-free-pool 設定値を超えることはありません。JMS は、その他のメッセージ リスナの場合と同じように、MDB インスタンスにメッセージを並列に配信します。MDB がクラスタ内の複数のサーバにデプロイされる場合、各サーバの各 MDB インスタンスに対してセッションが作成されます。
一方、トピックの場合、各メッセージのコピーを 1 つだけ作成し、1 つのトピック コンシューマを使用してメッセージを複数のスレッドに渡すことによって同時実行性を取得します。複数の MDB がデプロイされ、同じトピックをリスンする場合、各 MDB は各メッセージのコピーを受信します。このため、MDB が複数のサーバにデプロイされてトピックをリスンする場合、各サーバは各メッセージの独自のコピーを受信します。したがって、メッセージを 1 つの MDB によって処理するには、キューを使用してください。
Q. MDB はメッセージ プロデューサ、またはプロデューサとコンシューマの両方になれますか。
A. はい。MDB の内部に JMS コンテキストは存在しないので、接続、セッション、およびプロデューサを自分で確立する必要があります。そのための 1 つ目のオプションは、MDB の onMessage ルーチンに入るたびにこれを行うことです。メッセージ レートが相対的に低い場合、これで十分です。2 つ目のオプションは、ejbActivate() に必要なオブジェクトを確立することです。これらのオブジェクトはシリアライズ可能ではないので、ステートフル セッション Bean またはエンティティ Bean に対してパッシベーションを行うことができません。EJB が非アクティブ化した場合、関連付けられているオブジェクトをクローズする必要があります。3 番目のオプションは、起動クラスに JMS 接続/センダ セッション プールを構築し、独自の同期化とブロッキングを使用して完成させ、接続を取得することです。この例については、「メッセージ リスナ内からのメッセージの送受信は可能ですか。」を参照してください。
詳細については、『WebLogic JMS プログラマーズ ガイド』の「EJB とサーブレットでの JMS の使い方」を参照してください。
Q. MDB が恒久サブスクリプションを使用する場合、MDB がデプロイされないときにメッセージは蓄積されますか。
A. 恒久サブスクリプションは、MDB が最初にデプロイされるときに作成されます。恒久サブスクリプションは、MDB がアンデプロイまたは削除されても削除されません。このため、いったん MDB がデプロイされると、その MDB がアンデプロイまたは削除された場合でも、メッセージはサブスクリプションに蓄積され続けます。このため、MDB がサービスから廃止された場合、恒久サブスクリプションを削除してメッセージの蓄積を回避する必要があります。そのためには、Administration Console を使用するか、または恒久サブスクリプションの unsubscribe を呼び出す Java API を使用するスタンドアロン プログラムを記述します。
Q. 非 WebLogic JMS プロバイダの送り先を使用して MDB を駆動する方法を教えてください。
詳細については、JMS トピック ページの「Using foreign JMS providers with WebLogic Server」ホワイト ペーパー (jmsproviders.pdf) を参照してください。
Q. 外部 JMS プロバイダを使用してトランザクション対応 MDB を駆動できますか。
A. はい。WebLogic Server 7.0 以降では、外部 JMS プロバイダに対してコンテナ管理によるトランザクションをサポートする MDB をデプロイできます。MDB で、「transaction-type」属性が「Container」、「trans-attribute」属性が「Required」にコンフィグレーションされている場合、WebLogic Server は XA を使って外部 JMS プロバイダをトランザクションの中に自動的に取得します (コンテナ管理によるトランザクションを使用する MDB の例についての次の質問を参照してください)。
外部 JMS プロバイダが XA をサポートしていない場合、そのプロバイダではコンテナ管理によるトランザクションをサポートする MDB をデプロイすることはできません。また、JMS プロバイダが XA をサポートしている場合は、weblogic-ejb-jar.xml ファイル内で指定する JMS 接続ファクトリが XA をサポートするということを保証する必要があります。この指定方法は、各 JMS プロバイダでさまざまです。
外部プロバイダを使用するための MDB のコンフィグレーションの方法の例については、JMS トピック ページの「Using Foreign JMS Providers with WebLogic Server」ホワイト ペーパー (jmsproviders.pdf) を参照してください。
Q. トランザクションを MDB 内でロールバックするにはどのようにすればよいですか。
A. トランザクションをロールバックするには、次のコード例のとおり、Web Logic 拡張の TXHelper か、または MDB コンテキストを使用します。
UserTransaction ut =
weblogic.transaction.TXHelper.getUserTransaction();
ut.setRollbackOnly();
private MessageDrivenContext context;
public void setMessageDrivenContext(
MessageDrivenContext mycontext) {
context = mycontext;
}
public void onMessage(Message msg) {
try { // 何らかのロジック
}
catch(Exception e) {
System.out.println("MDB doing rollback");
context.setRollbackOnly();
}
Q. サーバ セッション プールとメッセージ駆動型 Bean を比較したいのですが。
A. このトピックの詳細については、JMS トピック ページの「BEA WebLogic JMS Performance Guide」ホワイト ペーパー (WebLogicJMSPerformanceGuide.pdf) の「MDBs vs. ServerSessionPools」を参照してください。
|
|
|