WebLogic JMS のコンフィグレーションと管理

     前  次    新しいウィンドウで目次を開く     
ここから内容の開始

WebLogic JMS のトラブルシューティング

WebLogic Server のこのリリースには、WebLogic 診断サービスが含まれています。これは、WebLogic Server プロセス内で実行され、標準のサーバ ライフサイクルに参加する、モニタおよび診断サービスです。このサービスを使用すると、実行中のサーバおよびそのコンテナ内にデプロイされているアプリケーションによって生成された診断データを作成、収集、分析、アーカイブし、それらの診断データにアクセスできます。このデータを基に、サーバおよびアプリケーションの実行時パフォーマンスを把握できます。また、障害発生時にこのデータを使用して障害の隔離や診断ができます。WebLogic JMS ではこのサービスを利用して、実行時の統計、キューやトピックに送信される通知、メッセージ ライフ サイクルのロギング、およびデバッグの機能を拡張し、WebLogic ドメインが円滑に実行され続けるよう支援します。

JMS の統計のモニタと JMS メッセージの管理の詳細については、「JMS 統計のモニタとメッセージの管理」を参照してください。

以下の節では、WebLogic JMS メッセージおよびコンフィグレーションのトラブルシューティングの方法について説明します。

 


JMS の通知のコンフィグレーション

「通知」は、監視ルールの評価が true となった場合にトリガされるアクションです。JMS 通知は、関連する監視のトリガに応じて JMS トピックまたは JMS キューにメッセージをポストするために使用します。システム リソース コンフィグレーション ファイルの <destination-jndi-name> 要素と <connection-factory-jndi-name> 要素で、メッセージの配信方法を定義します。

詳細については、『WebLogic 診断フレームワークのコンフィグレーションと使い方』の「通知のコンフィグレーション」を参照してください。

 


JMS のデバッグ

特定のアプリケーションに問題があると突き止めたら、WebLogic Server のデバッグ機能をアクティブ化して、アプリケーション内の特定の問題を探し当てることができます。

デバッグの有効化

デバッグは、適切な ServerDebug コンフィグレーション属性を true に設定することで有効化できます。必要に応じて、サーバの StdoutSeverityDebug に設定することもできます。

コンフィグレーション属性は、以下のいずれかの方法で修正できます。

コマンドラインを使用してデバッグを有効化する

コマンドラインで適切なプロパティを設定します。次に例を示します。

-Dweblogic.debug.DebugJMSBackEnd=true 
-Dweblogic.log.StdoutSeverity="Debug"

この方法は静的なもので、サーバの起動時にのみ使用できます。

WebLogic Server Administration Console を使用してデバッグを有効化する

WebLogic Server Administration Console を使用して、デバッグ値を設定します。

  1. まだ行っていない場合、Administration Console のチェンジ センタで [ロックして編集] をクリックします (「チェンジ センタの使用」を参照)。
  2. Administration Console の左ペインで、[環境] を展開して [サーバ] を選択します。
  3. [サーバの概要] ページで、デバッグを有効化または無効化するサーバをクリックして、そのサーバの設定ページを開きます。
  4. [デバッグ] をクリックします。
  5. [デフォルト] を展開します。
  6. 変更するデバッグ スコープまたは属性のチェック ボックスを選択します。
  7. [有効化](または [無効化]) を選択して、チェックを入れたデバッグ スコープまたは属性を有効化 (または無効化) します。
  8. Administration Console のチェンジ センタで [変更のアクティブ化] をクリックしてこれらの変更をアクティブ化します。
    すべての変更が即座に有効になるわけではありません。再起動が必要な場合もあります (「チェンジ センタの使用」を参照)。
  9. この方法は動的なもので、サーバの実行中にデバッグを有効化するのに使用できます。

WebLogic Scripting Tool を使用してデバッグを有効化する

WebLogic Scripting Tool (WLST) を使用してデバッグ値を設定します。たとえば、次のコマンドでは、debug.py というデバッグ値を設定するためのプログラムが実行されます。

java weblogic.WLST debug.py

メイン スコープである weblogic はグラフィックには表示されません。jms は weblogic 内のサブ スコープです。DebugJMSBackEnd の完全修飾された DebugScope は、weblogic.jms.backend です。

debug.py プログラムには、以下のコードが含まれています。

user='user1'
password='password'
url='t3://localhost:7001'
connect(user, password, url)
edit()
cd('Servers/myserver/ServerDebug/myserver')
startEdit()
set('DebugJMSBackEnd','true')
save()
activate()

Java からも WLST を使用することができます。次の例では、デバッグ値の設定に使用される Java ファイルを示します。

import weblogic.management.scripting.utils.WLSTInterpreter;
import java.io.*;
import weblogic.jndi.Environment;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

public class test {
public static void main(String args[]) {
try {
WLSTInterpreter interpreter = null;
String user="user1";
String pass="pw12ab";
String url ="t3://localhost:7001";
Environment env = new Environment();
env.setProviderUrl(url);
env.setSecurityPrincipal(user);
env.setSecurityCredentials(pass);
Context ctx = env.getInitialContext();

interpreter = new WLSTInterpreter();
interpreter.exec
("connect('"+user+"','"+pass+"','"+url+"')");
interpreter.exec("edit()");
interpreter.exec("startEdit()");
interpreter.exec
("cd('Servers/myserver/ServerDebug/myserver')");
interpreter.exec("set('DebugJMSBackEnd','true')");
interpreter.exec("save()");
interpreter.exec("activate()");

} catch (Exception e) {
System.out.println("Exception "+e);
}
}
}

WLST の使用は動的な方法であり、サーバの実行中にデバッグを有効化するのに使用できます。

config.xml ファイルへの変更

コンソール、WLST、またはコマンドラインでデバッグ特性を変更すると、その内容が config.xml ファイルに反映されます。

以下の config.xml のサンプル (抜粋) に、トランザクション デバッグのスコープ (複数のデバッグ属性) および 1 つの JMS 属性を示します。

コード リスト 8-1 JMS のデバッグに関するスタンザのサンプル
<server>
<name>myserver</name>
<server-debug>
<debug-scope>
<name>weblogic.transaction</name>
<enabled>true</enabled>
</debug-scope>
<debug-jms-back-end>true</debug-jms-back-end>
</server-debug>
</server>

JMS のデバッグ スコープ

java weblogic.diagnostics.debug.DebugScopeViewer を使うと DebugScope 定義をツリー表示できます。

以下に示す JMS 用の登録済みデバッグ スコープを有効化できます。

メッセージング カーネルとパス サービスのデバッグ スコープ

メッセージング カーネルとパス サービス用に、以下の登録済みデバッグ スコープを有効化できます。

要求の仕分け

これ以外のデバッグ方法としては、JMS サブシステムを介して個々の (通常は「仕分けされた」) アプリケーション リクエストのフローを追跡する方法があります。詳細については、『WebLogic 診断フレームワークのコンフィグレーションと使い方』の「DyeInjection モニタを介した仕分けベクトルのコンフィグレーション」を参照してください。

 


メッセージ ライフ サイクルのロギング

JMS ロギングは、JMS サーバを作成するとデフォルトで有効になります。ただし、この JMS サーバに対象指定する JMS モジュールのメッセージ送り先 (または送り先で使用する JMS テンプレート) では、JMS ロギングを明示的に有効にする必要があります。WebLogic ロギング サービスの詳細については、『ログ ファイルのコンフィグレーションとログ メッセージのフィルタ処理』の「WebLogic ロギング サービスについて」を参照してください。

メッセージのライフ サイクルとは、JMS メッセージが JMS サーバに届いた後、JMS API または JMS メッセージ管理 API を通じて、そのメッセージに順に発生するイベントを外側から見た概念です。メッセージ ライフ サイクルのロギングを利用することで、JMS サーバから見た JMS メッセージの存在やステータスに関する情報に容易にアクセスできます。各メッセージ ログには、メッセージの生成、消費、削除などの基本的なライフ サイクル イベントについての情報が含まれます。

ロギングは、長期間にわたって継続的に発生します。また、JMS サーバの実行中にリアルタイム モードで使用したり、JMS サーバの停止中にオフライン形式で使用したりすることも可能です。メッセージのロギングのコンフィグレーションについては、以下を参照してください。

JMS メッセージ ライフ サイクルのイベント

JMS 送り先のメッセージ ライフ サイクルのロギングを有効にすると、メッセージが基本的なメッセージ ライフ サイクル イベントに対応する条件を満たすたびに、JMS サーバのメッセージ ログ ファイルにレコードが追加されます。JMS メッセージのログ エントリは、以下のライフ サイクル イベントによってトリガされます。

メッセージ ログの場所

メッセージ ログは、ドメイン ディレクトリ内の次の場所に格納されます。

USER_DOMAIN\servers\servername\logs\jmsServers\jms_server_name\jms.messages.log

USER_DOMAIN はドメインのルート ディレクトリ (通常は c:\bea\user_projects\domains\USER_DOMAIN) です。これは、WebLogic Server プログラム ファイルが格納されるディレクトリ (通常は c:\bea\weblogic90) に対応するディレクトリです。

JMS メッセージ ロギングの有効化

キュー、トピック、JMS テンプレート、共通分散キュー、および共通分散トピックの JMS メッセージ ロギングは、WebLogic Server Administration Console を使用して有効にしたり無効にしたりできます。詳細については、以下を参照してください。

WebLogic Java Management Extensions (JMX) を使用すると、JMS メッセージ ログを管理するための JMSSystemResourceMBean および JMSRuntimeMBean の MBean にアクセスできます。詳細については、『JMX によるカスタム管理ユーティリティの開発』の「WebLogic Server サブシステム MBean の概要」を参照してください。

JMS サーバおよび JMS システム リソースの JMS メッセージ ロギングは、WebLogic Scripting Tool を使用してコンフィグレーションすることもできます。詳細については、「WLST を使用した JMS サーバと JMS システム モジュール リソースの管理」を参照してください。

メッセージ ロギングを有効にする際は、メッセージ ヘッダ フィールド、システム定義のメッセージ プロパティ、およびユーザ定義のプロパティのそれぞれについて、ログ エントリにそのすべてを含めるか一部のみを含めるかを指定できます。また、メッセージの本文を含めるかどうかも選択できます。メッセージ ヘッダおよびプロパティの詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS について」を参照してください。

 


JMS メッセージ ログの内容

ログに追加される各レコードには、メッセージに関する基本的な情報 (メッセージ ID、メッセージの件名の相関 ID など) が含まれます。JMS サーバをコンフィグレーションして、メッセージの種類やユーザ プロパティなどの追加情報を含めることもできます。

JMS メッセージ ログ レコードのフォーマット

特に注記のない限り、JMS メッセージ ライフ サイクル ログに追加されるすべてのレコードには、以下の情報が以下に列挙した順序で記録されます。

サンプル ログ ファイル レコード

以下に示すサンプル ログ ファイル レコードで、各メッセージ ライフ サイクル イベントでログ ファイルに記録される情報の種類を示します。各レコードは固定長ですが、イベントとの関連性やレコード内の各フィールドに有効な値が存在するかどうかに応じて含まれる情報が異なります。ログ ファイル レコードの構文は次のとおりです。

####<date_and_time_stamp> <transaction_id> <WLS_diagnostic_context> <date_in_milliseconds> <date_in_nanoseconds> <JMS_message_id> <JMS_correlation_id> <JMS_destination_name> <life_cycle_event_name> <JMS_user_name> <consumer_identifier> <JMS_message_content> <JMS_message_selector>
注意 : ログ ファイルに JMS メッセージのコンテンツを含めることを選択する場合は、メッセージのコンテンツ内のすべての左向きの山括弧 (<) と右向きの山括弧 (>) がエスケープされる点に注意してください。ログ ファイルでは、左向きの山括弧の代わりに &lt;、右向きの山括弧の代わりに &gt; が表示されます。

コンシューマ作成イベント

####<May 13, 2005 4:06:33 PM EDT> <> <> <1116014793818> <345063> <> <> <jmsfunc!TestQueueLogging> <ConsumerCreate> <system> <MC:CA(/10.61.6.56):OAMI(myserver.jms.connection456.session460.consumer462)> <> <> 

コンシューマ破棄イベント

####<May 13, 2005 4:06:33 PM EDT> <> <> <1116014793844> <40852> <> <> <jmsfunc!TestQueueLogging> <ConsumerDestroy> <system> <MC:CA(/10.61.6.56):OAMI(myserver.jms.connection456.session460.consumer462)> <> <> 

メッセージ生成イベント

####<May 13, 2005 4:06:43 PM EDT> <> <> <1116014803018> <693671> <ID:<327315.1116014803000.0>> <testSendRecord> <jmsfunc!TestQueueLoggingMarker> <Produced> <system> <> <&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;mes:WLJMSMessage xmlns:mes="http://www.bea.com/WLS/JMS/Message"&gt;&lt;mes:Header&gt;&lt;mes:JMSCorrelationID&gt;testSendRecord&lt;/mes:JMSCorrelationID&gt;&lt;mes:JMSDeliveryMode&gt;NON_PERSISTENT&lt;/mes:JMSDeliveryMode&gt;&lt;mes:JMSExpiration&gt;0&lt;/mes:JMSExpiration&gt;&lt;mes:JMSPriority&gt;4&lt;/mes:JMSPriority&gt;&lt;mes:JMSRedelivered&gt;false&lt;/mes:JMSRedelivered&gt;&lt;mes:JMSTimestamp&gt;1116014803000&lt;/mes:JMSTimestamp&gt;&lt;mes:Properties&gt;&lt;mes:property name="JMSXDeliveryCount"&gt;&lt;mes:Int&gt;0&lt;/mes:Int&gt;&lt;/mes:property&gt;&lt;/mes:Properties&gt;&lt;/mes:Header&gt;&lt;mes:Body&gt;&lt;mes:Text/&gt;&lt;/mes:Body&gt;&lt;/mes:WLJMSMessage&gt;> <> 

メッセージ消費イベント

####<May 13, 2005 4:06:45 PM EDT> <> <> <1116014805137> <268791> <ID:<327315.1116014804578.0>> <hello> <jmsfunc!TestQueueLogging> <Consumed> <system> <MC:CA(/10.61.6.56):OAMI(myserver.jms.connection456.session475.consumer477)> <&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;mes:WLJMSMessage xmlns:mes="http://www.bea.com/WLS/JMS/Message"&gt;&lt;mes:Header&gt;&lt;mes:JMSCorrelationID&gt;hello&lt;/mes:JMSCorrelationID&gt;&lt;mes:JMSDeliveryMode&gt;PERSISTENT&lt;/mes:JMSDeliveryMode&gt;&lt;mes:JMSExpiration&gt;0&lt;/mes:JMSExpiration&gt;&lt;mes:JMSPriority&gt;4&lt;/mes:JMSPriority&gt;&lt;mes:JMSRedelivered&gt;false&lt;/mes:JMSRedelivered&gt;&lt;mes:JMSTimestamp&gt;1116014804578&lt;/mes:JMSTimestamp&gt;&lt;mes:JMSType&gt;SendRecord&lt;/mes:JMSType&gt;&lt;mes:Properties&gt;&lt;mes:property name="JMS_BEA_RedeliveryLimit"&gt;&lt;mes:Int&gt;1&lt;/mes:Int&gt;&lt;/mes:property&gt;&lt;mes:property name="JMSXDeliveryCount"&gt;&lt;mes:Int&gt;1&lt;/mes:Int&gt;&lt;/mes:property&gt;&lt;/mes:Properties&gt;&lt;/mes:Header&gt;&lt;mes:Body&gt;&lt;mes:Text/&gt;&lt;/mes:Body&gt;&lt;/mes:WLJMSMessage&gt;> <> 

メッセージ期限切れイベント

####<May 13, 2005 4:06:47 PM EDT> <> <> <1116014807258> <445317> <ID:<327315.1116014807234.0>> <bar> <jmsfunc!TestQueueLogging> <Expired> <<WLS Kernel>> <> <&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;mes:WLJMSMessage xmlns:mes="http://www.bea.com/WLS/JMS/Message"&gt;&lt;mes:Header&gt;&lt;mes:JMSCorrelationID&gt;bar&lt;/mes:JMSCorrelationID&gt;&lt;mes:JMSDeliveryMode&gt;PERSISTENT&lt;/mes:JMSDeliveryMode&gt;&lt;mes:JMSExpiration&gt;1116014806234&lt;/mes:JMSExpiration&gt;&lt;mes:JMSPriority&gt;4&lt;/mes:JMSPriority&gt;&lt;mes:JMSRedelivered&gt;false&lt;/mes:JMSRedelivered&gt;&lt;mes:JMSTimestamp&gt;1116014807234&lt;/mes:JMSTimestamp&gt;&lt;mes:JMSType&gt;ExpireRecord&lt;/mes:JMSType&gt;&lt;mes:Properties&gt;&lt;mes:property name="JMS_BEA_RedeliveryLimit"&gt;&lt;mes:Int&gt;1&lt;/mes:Int&gt;&lt;/mes:property&gt;&lt;mes:property name="JMSXDeliveryCount"&gt;&lt;mes:Int&gt;0&lt;/mes:Int&gt;&lt;/mes:property&gt;&lt;/mes:Properties&gt;&lt;/mes:Header&gt;&lt;mes:Body&gt;&lt;mes:Text/&gt;&lt;/mes:Body&gt;&lt;/mes:WLJMSMessage&gt;> <> 

再試行超過イベント

####<May 13, 2005 4:06:53 PM EDT> <> <> <1116014813491> <394206> <ID:<327315.1116014813453.0>> <bar> <jmsfunc!TestQueueLogging> <Retry exceeded> <<WLS Kernel>> <> <&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;mes:WLJMSMessage xmlns:mes="http://www.bea.com/WLS/JMS/Message"&gt;&lt;mes:Header&gt;&lt;mes:JMSCorrelationID&gt;bar&lt;/mes:JMSCorrelationID&gt;&lt;mes:JMSDeliveryMode&gt;PERSISTENT&lt;/mes:JMSDeliveryMode&gt;&lt;mes:JMSExpiration&gt;0&lt;/mes:JMSExpiration&gt;&lt;mes:JMSPriority&gt;4&lt;/mes:JMSPriority&gt;&lt;mes:JMSRedelivered&gt;true&lt;/mes:JMSRedelivered&gt;&lt;mes:JMSTimestamp&gt;1116014813453&lt;/mes:JMSTimestamp&gt;&lt;mes:JMSType&gt;RetryRecord&lt;/mes:JMSType&gt;&lt;mes:Properties&gt;&lt;mes:property name="JMS_BEA_RedeliveryLimit"&gt;&lt;mes:Int&gt;1&lt;/mes:Int&gt;&lt;/mes:property&gt;&lt;mes:property name="JMSXDeliveryCount"&gt;&lt;mes:Int&gt;2&lt;/mes:Int&gt;&lt;/mes:property&gt;&lt;/mes:Properties&gt;&lt;/mes:Header&gt;&lt;mes:Body&gt;&lt;mes:Text/&gt;&lt;/mes:Body&gt;&lt;/mes:WLJMSMessage&gt;> <> 

メッセージ削除イベント

####<May 13, 2005 4:06:45 PM EDT> <> <> <1116014805071> <169809> <ID:<327315.1116014804859.0>> <hello> <jmsfunc!TestTopicLogging> <Removed> <system> <DS:messagelogging_client.foo.SendRecordSubscriber> <&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;mes:WLJMSMessage xmlns:mes="http://www.bea.com/WLS/JMS/Message"&gt;&lt;mes:Header&gt;&lt;mes:JMSCorrelationID&gt;hello&lt;/mes:JMSCorrelationID&gt;&lt;mes:JMSDeliveryMode&gt;PERSISTENT&lt;/mes:JMSDeliveryMode&gt;&lt;mes:JMSExpiration&gt;0&lt;/mes:JMSExpiration&gt;&lt;mes:JMSPriority&gt;4&lt;/mes:JMSPriority&gt;&lt;mes:JMSRedelivered&gt;false&lt;/mes:JMSRedelivered&gt;&lt;mes:JMSTimestamp&gt;1116014804859&lt;/mes:JMSTimestamp&gt;&lt;mes:JMSType&gt;SendRecordSubscriber&lt;/mes:JMSType&gt;&lt;mes:Properties&gt;&lt;mes:property name="JMSXDeliveryCount"&gt;&lt;mes:Int&gt;0&lt;/mes:Int&gt;&lt;/mes:property&gt;&lt;/mes:Properties&gt;&lt;/mes:Header&gt;&lt;mes:Body&gt;&lt;mes:Text/&gt;&lt;/mes:Body&gt;&lt;/mes:WLJMSMessage&gt;> <> 

JMS サーバ ログ ファイルの管理

JMS サーバを作成したら、古いログ メッセージを別のファイルに移動 (ローテーション) するための条件をコンフィグレーションできます。また、ログ ファイルのデフォルト名を変更することも可能です。

メッセージ ログ ファイルのローテーション

古いログ メッセージから新しいファイルへのローテーションは、ファイルが特定のサイズになったときに実施したり、指定した時間間隔で実施したりできます。また、古いログ メッセージのローテーションを実施しないことも選択できます。この場合は、すべてのメッセージが単一のファイルに蓄積され、ファイル サイズが大きくなり過ぎたときにはその中身を削除する必要があります。

ログ ファイルが特定のサイズに達したときに古いメッセージをローテーションすることを選択した場合は、最小限のファイル サイズを指定する必要があります。ログ ファイルが指定の最小サイズに到達すると、サーバが次回ファイル サイズをチェックする際に、現在のログ ファイルの名前が変更され、それ以降のメッセージを保存するための新規ログ ファイルが作成されます。

定期的な間隔で古いメッセージをローテーションすることを選択した場合は、最初の新しいログ ファイルが作成された時間と、そのファイルの名前が変更されて置換されるまでの時間間隔を指定する必要があります。

JMS サーバのログ ファイル ローテーションの設定ついては、Administration Console オンライン ヘルプの「JMS サーバ メッセージのログ ローテーションのコンフィグレーション」を参照してください。

メッセージ ログ ファイル名の変更

ローテーションされたログ ファイルは、作成順に番号付けされます。たとえば、7 番目にローテーションされたファイルは myserver.log00007 という名前になります。トラブルシューティングを容易にするため、ログ ファイルの名前を変更したり、ログ ファイルがローテーションされた日時を含めたりできます。ログ ファイル名に日時を含めるには、ファイル名に java.text.SimpleDateFormat 変数を追加します。それぞれの変数はパーセント記号 (%) で囲みます。ログ ファイルの名前の変更時に相対パス名を指定した場合、サーバのルート ディレクトリが基準と解釈されます。

JMS サーバのメッセージ ログ ファイル名の変更の詳細については、Administration Console オンライン ヘルプの「JMS サーバ メッセージのログ ローテーションのコンフィグレーション」を参照してください。

保存するメッセージ ログ ファイル数の制限

古いログ ファイルをファイル サイズまたは時間間隔に基づいてローテーションする場合は、古いメッセージの格納のために JMS サーバが作成するログ ファイルの数を制限することもできます。この制限に達すると、最も古いログ ファイルが削除され、最新のサフィックスの付いた新しいログ ファイルが作成されます。このオプションを有効にしない場合は新しいファイルが無限に作成されていくため、必要に応じてこれらのファイルを手動で削除する必要があります。

JMS サーバのメッセージ ログ ファイル数の制限の詳細については、Administration Console オンライン ヘルプの「JMS サーバ メッセージのログ ローテーションのコンフィグレーション」を参照してください。

 


送り先でのメッセージ処理の制御

WebLogic JMS コンフィグレーションおよび実行時 API を使用すると、メッセージの生成、挿入、および消費の処理を休止したり再開したりできます。休止および再開が可能なのは、JMS 送り先または一時的な送り先、同じテンプレートを使用してコンフィグレーションされた送り先のグループ、および単一の JMS サーバによってホストされるすべての送り先において、プログラム的に (JMX や実行時 MBean API を使用して) または管理上の理由で (Administration Console を使用して) 実行されるメッセージ処理です。外部リソースに障害が発生したとき、JMS サブシステムがメッセージの受け付けと配信 (および再配信) を継続すると、システムに過度の負荷がかかることがあります。しかし、メッセージ処理を休止 (および再開) することで、外部リソースの障害発生時の JMS サブシステムの動作を制御できます。

JMS サーバおよび「休止」状態にあるその送り先を起動すると、それらの送り先でのメッセージの生成、挿入、または消費が起動後直ちに休止します。その後管理者が休止している送り先の状態を「再開」に変更すると、通常のメッセージ処理アクティビティ (生成、挿入、または消費) が再開します。また、新しい実行時オプションを使用すると、実行中の送り先の現在の状態を変更して、新しいメッセージの生成、挿入、または消費を許可または禁止できます。

メッセージの生成、挿入、および消費とは

送り先では、メッセージに対してさまざまな処理が実行されます。

以下の節で説明するように、起動時または実行時にこれらの処理のいずれかまたはすべてを休止できます。

休止と再開をロギングする

送り先でのメッセージの生成、挿入、または消費を、起動時または実行時に正常に「休止」または「再開」させると、そのことを示すメッセージがサーバ ログに追加されます。送り先でのメッセージの生成、挿入、消費の休止または再開に失敗した場合は、適切なエラーまたは例外がログに記録されます。

生成の休止と生成の再開

JMS 送り先での「生成が休止」されると、その送り先にアタッチされている新しいプロデューサと既存のプロデューサにおいて、その送り先に対する新しいメッセージを生成できなくなります。休止している送り先に対してプロデューサがメッセージを送信しようとすると、送り先が休止していることを示す例外が返されます。送り先で「休止していた生成が再開」されると、新しいメッセージの生成が再び許可されます。メッセージの生成の休止では、処理中の作業の結果であるメッセージの挿入は休止されません。

注意 : 処理中の作業の構成要素については、「処理中の作業とは」を参照してください。

起動時に生成を休止、再開する

起動時には、JMS サーバのすべての送り先、同じ JMS テンプレートを指す送り先のグループ、または個別の送り先での生成を休止または再開できます。production-paused-at-startup をコンフィグレーションした場合は、指定した送り先でのメッセージの生成アクティビティが次回のサーバ起動時に禁止され、その送り先の状態を明示的に「生成が有効化された」状態に変更するまで継続します。生成の再開をコンフィグレーションした場合は、指定した送り先でのメッセージの生成アクティビティが次回のサーバ起動時に許可され、その送り先の状態を明示的に「生成の休止」状態に変更するまで継続します。

Administration Console を使用して起動時にメッセージの生成を休止および再開する方法については、以下を参照してください。

注意 : この処理はレベル (JMS サーバ レベル、JMS テンプレート レベル、スタンドアロンの送り先レベル、共通分散送り先レベルなど) ごとにコンフィグレーションできるため、レベル間での優先順位が確立されています。詳細については、「起動時のメッセージ処理の休止と再開の優先順位」を参照してください。

実行時に生成を休止、再開する

実行時には、JMS サーバで対象指定されているすべての送り先、同じ JMS テンプレートを指す送り先のグループ、または個別の送り先での生成を休止または再開できます。コンフィグレーションの変更がどのレベル (JMS サーバ レベル、JMS テンプレート レベル、または送り先レベル) で行われたかに関係なく、最も新しく変更されたコンフィグレーションが常に優先されます。

実行時の生成の休止および再開の詳細については、以下を参照してください。

生成の休止、再開と分散送り先

メンバー送り先での生成が休止されると、プロデューサによる生成においてそのメンバー送り先が考慮されなくなります。メッセージは、生成が可能な他のメンバー送り先に向けて送信されます。

生成の休止、再開と JMS 接続の停止、開始

JMS 接続を停止または開始しても、送り先の生成休止状態や生成再開状態には影響しません。

挿入の休止と挿入の再開

JMS 送り先での「挿入」が休止されると、処理中の作業の結果として挿入されるメッセージと、プロデューサによって送信された新しいメッセージの両方が、送り先に現れなくなります。すべてのメッセージが送り先に現れないようにするには、挿入の休止を使用します。

処理中の作業が保留になっているかどうかを特定するには、Administration Console の統計を調べます。送り先でのメッセージの「挿入」を休止すると、処理中の作業完了に関係するメッセージが「配信不可」になり、新しいメッセージの生成処理が失敗します。コンシューマではこれらのメッセージがすべて「認識不可」になり、保留中でなくなったメッセージを反映するため統計が調整されます。

「挿入」の休止処理は、「生成」の休止処理よりも優先されます。つまり、送り先が現在「生成の休止」状態にある場合は、「挿入の休止」状態に変更できます。

処理中のメッセージが送り先に現れるようにするには、その送り先でのメッセージの挿入を明示的に「再開」する必要があります。挿入の「再開」処理が正常に完了すると、送り先が「挿入が有効化された」状態になり、「認識不可」だった処理中のメッセージがすべて認識可能になります。

起動時に挿入を休止、再開する

起動時には、JMS サーバのすべての送り先、同じ JMS テンプレートを指す送り先のグループ、または個別の送り先での挿入を休止または再開できます。insertion-paused-at-startup をコンフィグレーションした場合は、指定した送り先でのメッセージの挿入および生成アクティビティが次回のサーバ起動時に禁止され、その送り先の状態を明示的に「挿入が有効化された」状態に変更するまで継続します。挿入の再開をコンフィグレーションした場合は、指定した送り先でのメッセージの挿入アクティビティが次回のサーバ起動時に許可され、その送り先の状態を明示的に「挿入の休止」状態に変更するまで継続します。

起動時のメッセージの挿入の休止および再開の詳細については、以下を参照してください。

注意 : この処理はレベル (JMS サーバ レベル、JMS テンプレート レベル、送り先レベルなど) ごとにコンフィグレーションできるため、レベル間での優先順位が確立されています。詳細については、「起動時のメッセージ処理の休止と再開の優先順位」を参照してください。

実行時に挿入を休止、再開する

実行時には、JMS サーバのすべての送り先、同じ JMS テンプレートを指す送り先のグループ、または個別の送り先での挿入を休止または再開できます。コンフィグレーションの変更がどのレベル (JMS サーバ レベル、JMS テンプレート レベル、または送り先レベル) で行われたかに関係なく、最も新しく変更されたコンフィグレーションが常に優先されます。

実行時の挿入の休止および再開の詳細については、以下を参照してください。

挿入の休止、再開と分散送り先

メンバー送り先での挿入が休止されると、メッセージの転送においてそのメンバー送り先が考慮されなくなります。メッセージは、挿入が可能な他のメンバー送り先に向けて送信されます。

挿入の休止、再開と JMS 接続の停止、開始

JMS 接続を停止または開始しても、送り先の挿入休止状態や挿入再開状態には影響しません。

消費の休止と消費の再開

JMS 送り先での「消費が休止」されると、その送り先のメッセージが消費できなくなります。JMS 送り先での「消費の休止が再開」されると、その送り先にアタッチされている新しいコンシューマと既存のコンシューマが、その送り先のメッセージを消費できるようになります。

送り先での消費が休止されると、送り先の状態が「消費の休止」とマークされ、消費が再開されてメッセージが消費可能になるまで、すべての新しい同期受信処理がブロックされます。ブロッキング タイムアウト処理を伴うすべての同期受信は、指定した時間の間ブロックされます。送り先での消費が休止している間は、その送り先にアタッチされている同期コンシューマへのメッセージは配信されません。

消費の「休止」処理が正常に行われた後、その送り先で消費処理を行えるようにするには、ユーザが送り先を明示的に「再開」する必要があります。

起動時に消費を休止、再開する

起動時には、JMS サーバのすべての送り先、同じ JMS テンプレートを指す送り先のグループ、または個別の送り先での消費を休止または再開できます。consumption-paused-at-startup をコンフィグレーションした場合は、指定した送り先のメッセージの消費アクティビティが次回のサーバ起動時に禁止され、その送り先の状態を明示的に「消費が有効化された」状態に変更するまで継続します。消費の再開をコンフィグレーションした場合は、指定した送り先でのメッセージ消費アクティビティが次回のサーバ起動時に許可され、その送り先の状態を明示的に「消費の休止」状態に変更するまで継続します。

起動時の消費の休止および再開の詳細については、以下を参照してください。

実行時に消費を休止、再開する

実行時には、JMS サーバのすべての送り先、同じ JMS テンプレートを指す送り先のグループ、または個別の送り先での消費を休止または再開できます。コンフィグレーションの変更がどのレベル (JMS サーバ レベル、JMS テンプレート レベル、または送り先レベル) で行われたかに関係なく、最も新しく変更されたコンフィグレーションが常に優先されます。

実行時の消費の休止および再開の詳細については、以下を参照してください。

消費の休止、再開とキュー ブラウザ

キュー ブラウザは、キュー送り先の「参照」のみが可能な特殊なタイプのコンシューマです。消費が休止されている送り先でも参照処理は禁止されません。

消費の休止、再開と分散送り先

消費が休止されているメンバー送り先は、コンシューマのロード バランシング アルゴリズムでは考慮されません。

消費の休止、再開とメッセージ駆動型 Bean

送り先での消費を休止すると、メッセージ駆動型 Bean (MDB) が関連する送り先からのメッセージを取得できなくなります。この機能を使用すると、接続の開始/停止を使用する場合と比較して、より柔軟に個別の送り先レベルからの MDB へのメッセージの配信を制御できます。つまり、消費の休止/再開機能を使用すると、JMS 接続を複数の MDB で共有している場合でも、関連付けられた送り先での消費を休止することによって、特定の MDB へのメッセージの配信を禁止できるということです。

MDB の使用方法の詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「メッセージ駆動型 EJB」を参照。

消費の休止、再開と JMS 接続の停止、開始

JMS 接続の停止/開始機能では、コンシューマが受信 API を正常に呼び出したかどうかが判別されます。送り先での消費の休止/再開機能では、受信呼び出しにおいて送り先からメッセージを取得したかどうかが判別されます。コンシューマの接続を停止または開始しても、送り先の消費の休止状態には影響しません。

送り先での消費が休止されている場合、コンシューマの接続が「停止」状態から「開始」に変更されると、同期受信処理がブロックされるかタイムアウトします。非同期コンシューマが関連付けられている送り先が「消費の休止」状態にあると、非同期コンシューマはメッセージを受信しません。

処理中の作業とは

プロデューサに関連付けられる処理中の作業

メッセージ プロデューサに関連付けられた処理中の作業の結果として、送り先において以下の種類のメッセージが挿入されます。

コンシューマに関連付けられる処理中の作業

メッセージ コンシューマに関連付けられた処理中の作業の結果として、送り先において以下の種類のメッセージが挿入されます。

起動時のメッセージ処理の休止と再開の優先順位

起動時に、送り先の休止や再開をさまざまなレベルの属性で設定できます。

これらの各レベルの値が起動時に一致していない場合、指定した送り先でのメッセージ処理は以下の優先順位に基づいて決定されます。メッセージ処理の休止および再開をコンフィグレーションするための各属性において、

  1. 送り先をホストする JMS サーバの属性セットに有効な値が設定されている場合は、その値に基づいて起動時の送り先の状態が決定されます。サーバ レベルの設定が最も優先されます。
  2. 送り先をホストする JMS サーバの属性セットに有効な値が設定されていない場合は、送り先レベルの属性の値が 2 番目に優先され、その値に基づいて起動時の送り先の状態が決定されます。
  3. 送り先をホストする JMS サーバおよび送り先の属性セットに有効な値が設定されていない場合は、JMS テンプレートの属性の値に基づいて起動時の送り先の状態が決定されます。
  4. これら 3 つのレベルのすべてで属性が設定されていない場合は、値が「false」に設定されているものと見なされます。

セキュリティ

管理ユーザや管理グループは、その時点で送り先の状態が他のユーザによって制御されているかどうかに関係なく、送り先の現在の状態をオーバーライドできます。

2 人の非管理ユーザが送り先の状態を制御しようとした場合、以下の規則が適用されます。

  1. 送り先の状態を「休止」に変更したユーザと同じグループに属すユーザのみが、その送り先を「再開」して通常の処理に戻すことができます。
  2. 別のグループに属す 2 人のユーザが状態を変更しようとした場合、変更は許可されません。


  ページの先頭       前  次