| Oracle® Fusion Middleware Oracle WebLogic Server JMSの構成と管理 11g リリース1 (10.3.6) B61636-06 |
|
 前 |
| Oracle® Fusion Middleware Oracle WebLogic Server JMSの構成と管理 11g リリース1 (10.3.6) B61636-06 |
|
前 |
この章では、WebLogic JMSのメッセージおよび構成のトラブルシューティングの方法について説明します。
JMSの統計のモニターとJMSメッセージの管理の詳細は、第8章「JMS統計のモニターとメッセージの管理」を参照してください。
「通知」は、監視ルールの評価がtrueとなった場合にトリガーされるアクションです。JMS通知は、関連する監視のトリガーに応じてJMSトピックまたはJMSキューにメッセージをポストするために使用します。システム・リソース構成ファイルの<destination-jndi-name>要素と<connection-factory-jndi-name>要素で、メッセージの配信方法を定義します。
詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』の通知の構成に関する項を参照してください。
特定のアプリケーションに問題があると突き止めたら、WebLogic Serverのデバッグ機能をアクティブ化して、アプリケーション内の特定の問題を探し当てることができます。
デバッグは、適切なServerDebug構成属性をtrueに設定することで有効化できます。必要に応じて、サーバーのStdoutSeverityをDebugに設定することもできます。
構成属性は、以下のいずれかの方法で変更できます。
コマンド・ラインで適切なプロパティを設定します。例:
-Dweblogic.debug.DebugJMSBackEnd=true -Dweblogic.log.StdoutSeverity="Debug"
この方法は静的なものであり、サーバーの起動時にのみ使用できます。
WebLogic Server管理コンソールを使用して、デバッグ値を設定します。
まだ行っていない場合、管理コンソールの「チェンジ・センター」で「ロックして編集」をクリックします(『Oracle WebLogic Serverの紹介』のチェンジ・センターの使用に関する項を参照)。
管理コンソールの左ペインで、「環境」を展開して「サーバー」を選択します。
「サーバーのサマリー」ページで、デバッグを有効化または無効化するサーバーをクリックして、そのサーバーの設定ページを開きます。
「デバッグ」をクリックします。
「デフォルト」を展開します。
変更するデバッグ・スコープまたは属性のチェック・ボックスを選択します。
「有効化」(または「無効化」)を選択して、選択したデバッグ・スコープまたは属性を有効化(または無効化)します。
管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
すべての変更がすぐに有効になるわけではありません。再起動が必要な場合もあります(『Oracle WebLogic Serverの紹介』のチェンジ・センターの使用に関する項を参照)。
この方法は動的なものであり、サーバーの実行中にデバッグを有効化するのに使用できます。
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の使用は動的な手法で、サーバーの実行中にデバッグを有効化するために使用できます。
次は、JMSの登録されたデバッグ・スコープです。
DebugJMSBackEnd (スコープはweblogic.jms.backend) - JMSバック・エンドのデバッグ情報(分散宛先やJMS SAF用に使用される情報を含む)を出力します。
DebugJMSFrontEnd (スコープはweblogic.jms.frontend) - JMSフロント・エンドのデバッグ情報(マルチキャスト用に使用される情報を含む)を出力します。
DebugJMSCommon (スコープはw blogic.jms.common) - JMS共通メソッドのデバッグ情報(クライアントJMSプロデューサからの情報を含む)を出力します。
DebugJMSConfig (スコープはweblogic.jms.config) - JMSの構成(バックエンド、分散宛先、外部サーバー)に関する情報を出力します。
DebugJMSBoot (スコープはweblogic.jms.boot) - JMSサーバーが使用しているストアと、構成されている宛先に関するメッセージを起動時に出力します。
DebugJMSDispatcher (スコープはweblogic.jms.dispatcher) - PeerGone()の発生回数に関する情報を出力します。
DebugJMSDistTopic (スコープはweblogic.jms.config) - 分散トピックの情報と、主要なバインドおよびアンバインドの情報を出力します。
DebugJMSPauseResume (スコープはweblogic.jms.pauseresume) - 宛先における処理の休止と再開(バックエンド)に関する情報を出力します。
DebugJMSModule (スコープはweblogic.jms.module) - JMSモジュールの処理とメッセージ・ライフ・サイクルに関する多くの情報を出力します。
DebugJMSMessagePath (スコープはweblogic.jms.messagePath) - メッセージ・パス(クライアント、フロントエンド、バックエンド)を経由するメッセージの追跡情報(メッセージIDを含む)を出力します。
DebugJMSSAF (スコープweblogic.jms.saf) - JMS SAF (ストア・アンド・フォワード)宛先に関する情報を出力します。
DebugJMSCDS (スコープはweblogic.jms.CDS) - JMSの「構成ディレクトリ・サービス」に関する詳細な情報を出力します(このサービスは、サーバーに構成されているJMSリソースの構成の変更を知らせる通知を、クラスタ内だけでなく複数のクラスタやドメインに渡る範囲から取得するために、様々なサブ・システムで使用されます)。
DebugJMSWrappers (スコープはweblogic.jms.wrappers) - JMS接続、セッション、および他のオブジェクトの、プーリングとラッピングに関する情報を出力します(この情報はデプロイメント記述子のresource-reference要素を利用してEJB内またはサーブレット内で使用されます)。
次は、メッセージング・カーネルとパス・サービスの登録されたデバッグ・スコープです。
DebugMessagingKernel (スコープはweblogic.messaging.kernel) - メッセージング・カーネルに関する情報を出力します。
DebugMessagingKernelBoot (スコープはweblogic.messaging.kernelboot) - メッセージング・カーネルの起動に関する情報(処理メッセージ)を出力します。
DebugPathSvc (スコープはweblogic.messaging.pathsvc) - パス・サービスにおける一部の異常な状況に関する限定された情報を出力します。
DebugPathSvcVerbose (スコープはweblogic.messaging.pathsvcverbose) - パス・サービスにおける異常な状況に関する限定された情報を出力します。
JMSロギングは、JMSサーバーを作成するとデフォルトで有効になります。しかし、このJMSサーバーにターゲット指定するJMSモジュールのメッセージ宛先(または宛先で使用するJMSテンプレート)では、JMSロギングを明示的に有効にする必要があります。WebLogicロギング・サービスの詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』のWebLogicロギング・サービスの理解に関する項を参照してください。
メッセージのライフ・サイクルとは、JMSメッセージがJMSサーバーに届いた後、JMS APIまたはJMSメッセージ管理APIを通じて、そのメッセージに順に発生するイベントを外側から見た概念です。メッセージ・ライフ・サイクルのロギングを利用することで、JMSサーバーから見たJMSメッセージの存在やステータスに関する情報に容易にアクセスできます。各メッセージ・ログには、メッセージの生成、消費、削除などの基本的なライフ・サイクル・イベントについての情報が含まれます。
ロギングは、長期間にわたって継続的に発生します。また、JMSサーバーの実行中にリアルタイム・モードで使用したり、JMSサーバーの停止中にオフライン形式で使用したりすることも可能です。メッセージ・ロギングの構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のトピックを参照してください。
JMS宛先のメッセージ・ライフ・サイクルのロギングを有効にすると、メッセージが基本的なメッセージ・ライフ・サイクル・イベントに対応する条件を満たすたびに、JMSサーバーのメッセージ・ログ・ファイルにレコードが追加されます。JMSメッセージのログ・エントリは、以下のライフ・サイクル・イベントによってトリガーされます。
生成 - このイベントは、WebLogic Server JMS APIまたはJMS Management APIを介してメッセージがJMSサーバーに受信されたときにログに記録されます。
消費 - このイベントは、WebLogic Server JMS APIまたはJMS Management APIを介してメッセージがJMSサーバーから送信されたときにログに記録されます。
削除 - このイベントは、WebLogic Server JMS APIまたはJMS Management APIを介してメッセージがJMSサーバーから手動で削除されたときにログに記録されます。
期限切れ - このイベントは、メッセージがJMSサーバーに格納された有効期限に達したときにログに記録されます。メッセージを受信したトピック・サブスクライバごとに別々に期限切れイベントが発生しても、イベントが複数回ログに記録されることはありません。
再試行超過 - このイベントは、メッセージが再配信の再試行制限を超えたときにログに記録されます。トピック・サブスクライバごとに再配信回数が異なる場合は、このイベントが1つのメッセージについて複数回記録されることもあります。
コンシューマ作成 - このイベントは、キューのJMSコンシューマが作成されるか、トピックのJMS恒久サブスクライバが作成されたときにログに記録されます。
コンシューマ破棄 - このイベントは、JMSコンシューマがクローズされるか、トピックのJMS恒久サブスクライバがアンサブスクライブされたときにログに記録されます。
メッセージ・ログは、ドメイン・ディレクトリ内の次の場所に格納されます。
USER_DOMAIN\servers\servername\logs\jmsServers\jms_server_name\jms.messages.log
USER_DOMAINはドメインのルート・ディレクトリ(通常はc:\Oracle\Middleware\user_projects\domains\USER_DOMAIN)です。これは、WebLogic Serverプログラム・ファイルが格納されるディレクトリ(通常はc:\Oracle\Middleware\wlserver_10.3)に対応するディレクトリです。
キュー、トピック、JMSテンプレート、共通分散キュー、および共通分散トピックのJMSメッセージ・ロギングは、WebLogic Server管理コンソールを使用して有効にしたり無効にしたりできます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のトピックを参照してください。
WebLogic Java Management Extensions (JMX)を使用すると、JMSメッセージ・ログを管理するためのJMSSystemResourceMBeanおよびJMSRuntimeMBeanのMBeanにアクセスできます。詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic ServerサブシステムMBeanの概要に関する項を参照してください。
|
注意: 非恒久サブスクリプションのJMSメッセージ・ロギングは、デフォルト構成では有効化されていません。有効化するには、システム・プロパティ |
JMSサーバーおよびJMSシステム・リソースのJMSメッセージ・ロギングは、WebLogic Scripting Toolを使用して構成することもできます。詳細については、第6章「WLSTを使用したJMSサーバーとJMSシステム・モジュール・リソースの管理」を参照してください。
メッセージ・ロギングを有効にする際は、メッセージ・ヘッダー・フィールド、システム定義のメッセージ・プロパティ、およびユーザー定義のプロパティのそれぞれについて、ログ・エントリにそのすべてを含めるか一部のみを含めるかを指定できます。また、メッセージの本文を含めるかどうかも選択できます。メッセージのヘッダーおよびプロパティの詳細は、『Oracle WebLogic Server JMSのプログラミング』の基本的なJMSアプリケーションの開発に関する項を参照してください。
ログに追加される各レコードには、メッセージに関する基本的な情報(メッセージID、メッセージの件名の相関IDなど)が含まれます。JMSサーバーを構成して、メッセージの種類やユーザー・プロパティなどの追加情報を含めることもできます。
特に注記のない限り、JMSメッセージ・ライフ・サイクル・ログに追加されるすべてのレコードには、以下の情報が以下に列挙した順序で記録されます。
日付 - このメッセージのログ・レコードが生成された日時。
トランザクション識別子 - メッセージが関連付けられているトランザクションのトランザクション識別子。
WLS診断コンテキスト - システム内を流れるリクエストまたは作業単位の一意の識別子。この情報がJMSメッセージ・ログに含まれているのは、同じリクエストに属すイベント間の相関性を示すためです。
「日付」の生のミリ秒値 - メッセージ・ログ・レコードが生成された日時をミリ秒で表した値。トラフィック量の多いアプリケーションでのトラブルシューティングに使用します。
「日付」の生のナノ秒値 - メッセージ・ログ・レコードが生成された日時をナノ秒で表した値。トラフィック量の多いアプリケーションでのトラブルシューティングに使用します。
JMSメッセージID - メッセージに割り当てられた一意の識別子。
JMS相関ID - メッセージのユーザー定義の識別子。通常は件名が同じメッセージの相関に使用します。
JMS宛先名 - メッセージの宛先サーバーの完全修飾名。
JMSメッセージ・ライフ・サイクル・イベント名 - ログ・エントリをトリガーしたメッセージ・ライフ・サイクル・イベントの名前。
JMSユーザー名 - メッセージを生成、消費、または受信したユーザーの名前。
JMSメッセージ・コンシューマ識別子 - この情報は、ログに記録されたメッセージ・ライフ・サイクル・イベントが、「消費」イベント、「コンシューマ作成」イベント、または「コンシューマ破棄」イベントである場合にのみログに含まれます。メッセージがキュー上で消費された場合は、コンシューマの起点と、JMSサーバーで識別されたコンシューマのOAM識別子に関する情報がログに含まれます。コンシューマが恒久サブスクライバである場合は、ログに接続のクライアントIDとサブスクリプション名も含まれます。
メッセージ・コンシューマ識別子の構文は次のとおりです。
MC:CA(…):OAMI(wls_server_name.jms.connection#.session#.consumer#)
説明:
MCはメッセージ・コンシューマを表します。
CAはクライアント・アドレスを表します。
OAMIはOA&M識別子を表します。
CCは接続コンシューマを表します(適用される場合のみ)。
コンシューマが恒久サブスクライバである場合は、追加情報が次の構文で表示されます。
DS:client_id.subscription_name[message consumer identifier]
DSは恒久サブスクライバを表します。
JMSメッセージ・コンテンツ - 宛先ごとにカスタマイズ可能なフィールド。ただし、メッセージの本文は使用できません。
JMSメッセージ・セレクタ - この情報は、ログに記録されたメッセージ・ライフ・サイクル・イベントが「コンシューマ作成」イベントである場合にのみログに含まれます。ログには、JMS APIからのselector引数が表示されます。
以下に示すサンプル・ログ・ファイル・レコードで、各メッセージ・ライフ・サイクル・イベントでログ・ファイルに記録される情報の種類を示します。各レコードは固定長ですが、イベントとの関連性やレコード内の各フィールドに有効な値が存在するかどうかに応じて含まれる情報が異なります。ログ・ファイル・レコードの構文は次のとおりです。
####<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メッセージのコンテンツを含めることを選択する場合は、メッセージのコンテンツ内のすべての左向きの山カッコ(<)と右向きの山カッコ(>)がエスケープされる点に注意してください。ログ・ファイルでは、左向きの山カッコのかわりに"<"、右向きの山カッコのかわりに">"が表示されます。 |
####<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> <> <<?xml version="1.0" encoding="UTF-8"?> <mes:WLJMSMessage xmlns:mes="http://www.bea.com/WLS/JMS/Message"><mes:Header><mes:JMSCor relationID>testSendRecord</mes:JMSCorrelationID><mes:JMSDeliveryMode >NON_PERSISTENT</mes:JMSDeliveryMode><mes:JMSExpiration>0< /mes:JMSExpiration><mes:JMSPriority>4</mes:JMSPriority>< mes:JMSRedelivered>false</mes:JMSRedelivered><mes:JMSTimestamp> 1116014803000</mes:JMSTimestamp><mes:Properties><mes:property name="JMSXDeliveryCount"><mes:Int>0</mes:Int></mes:property ></mes:Properties></mes:Header><mes:Body><mes:Text/> </mes:Body></mes:WLJMSMessage>> <>
####<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)> <<?xml version="1.0" encoding="UTF-8"?> <mes:WLJMSMessage xmlns:mes="http://www.bea.com/WLS/JMS/Message"><mes:Header><mes: JMSCorrelationID>hello</mes:JMSCorrelationID><mes:JMSDeliveryMode >PERSISTENT</mes:JMSDeliveryMode><mes:JMSExpiration>0</mes: JMSExpiration><mes:JMSPriority>4</mes:JMSPriority><mes: JMSRedelivered>false</mes:JMSRedelivered><mes:JMSTimestamp> 1116014804578</mes:JMSTimestamp><mes:JMSType>SendRecord</mes: JMSType><mes:Properties><mes:property name="JMS_BEA_RedeliveryLimit"><mes:Int>1</mes:Int></mes:property><mes: property name="JMSXDeliveryCount"><mes:Int>1</mes:Int></mes:property> </mes:Properties></mes:Header><mes:Body><mes:Text/></mes:Body></mes:WLJMSMessage>> <>
####<May 13, 2005 4:06:47 PM EDT> <> <> <1116014807258> <445317> <ID:<327315.1116014807234.0>> <bar> <jmsfunc!TestQueueLogging> <Expired> <<WLS Kernel>> <> <<?xml version="1.0" encoding="UTF-8"?> <mes:WLJMSMessage xmlns:mes="http://www.bea.com/WLS/JMS/Message"><mes:Header><mes: JMSCorrelationID>bar</mes:JMSCorrelationID><mes:JMSDeliveryMode> PERSISTENT</mes:JMSDeliveryMode><mes:JMSExpiration>1116014806234 </mes:JMSExpiration><mes:JMSPriority>4</mes:JMSPriority>< mes:JMSRedelivered>false</mes:JMSRedelivered><mes:JMSTimestamp> 1116014807234</mes:JMSTimestamp><mes:JMSType>ExpireRecord</mes: JMSType><mes:Properties><mes:property name="JMS_BEA_RedeliveryLimit"><mes:Int>1</mes:Int></mes:property><mes: property name="JMSXDeliveryCount"><mes:Int>0</mes:Int></mes:property> </mes:Properties></mes:Header><mes:Body><mes:Text/></mes:Body></mes:WLJMSMessage>> <>
####<May 13, 2005 4:06:53 PM EDT> <> <> <1116014813491> <394206> <ID:<327315.1116014813453.0>> <bar> <jmsfunc!TestQueueLogging> <Retry exceeded> <<WLS Kernel>> <> <<?xml version="1.0" encoding="UTF-8"?> <mes:WLJMSMessage xmlns:mes="http://www.bea.com/WLS/JMS/Message"><mes:Header><mes: JMSCorrelationID>bar</mes:JMSCorrelationID><mes:JMSDeliveryMode> PERSISTENT</mes:JMSDeliveryMode><mes:JMSExpiration>0</mes: JMSExpiration><mes:JMSPriority>4</mes:JMSPriority><mes: JMSRedelivered>true</mes:JMSRedelivered><mes:JMSTimestamp> 1116014813453</mes:JMSTimestamp><mes:JMSType>RetryRecord</mes: JMSType><mes:Properties><mes:property name="JMS_BEA_RedeliveryLimit"><mes:Int>1</mes:Int></mes:property><mes: property name="JMSXDeliveryCount"><mes:Int>2</mes:Int></mes:property ></mes:Properties></mes:Header><mes:Body><mes:Text/> </mes:Body></mes:WLJMSMessage>> <>
####<May 13, 2005 4:06:45 PM EDT> <> <> <1116014805071> <169809> <ID:<327315.1116014804859.0>> <hello> <jmsfunc!TestTopicLogging> <Removed> <system> <DS:messagelogging_client.foo.SendRecordSubscriber> <<?xml version="1.0" encoding="UTF-8"?> <mes:WLJMSMessage xmlns:mes="http://www.bea.com/WLS/JMS/Message"><mes: Header><mes:JMSCorrelationID>hello</mes:JMSCorrelationID><mes: JMSDeliveryMode>PERSISTENT</mes:JMSDeliveryMode><mes:JMSExpiration >0</mes:JMSExpiration><mes:JMSPriority>4</mes:JMSPriority> <mes:JMSRedelivered>false</mes:JMSRedelivered><mes:JMSTimestamp >1116014804859</mes:JMSTimestamp><mes:JMSType> SendRecordSubscriber</mes:JMSType><mes:Properties><mes:property name="JMSXDeliveryCount"><mes:Int>0</mes:Int></mes:property ></mes:Properties></mes:Header><mes:Body><mes:Text/></mes:Body></mes:WLJMSMessage>> <>
JMSサーバーを作成したら、古いログ・メッセージを別のファイルに移動(ローテーション)するための条件を構成できます。また、ログ・ファイルのデフォルト名を変更することも可能です。
古いログ・メッセージから新しいファイルへのローテーションは、ファイルが特定のサイズになったときに実施したり、指定した時間間隔で実施したりできます。また、古いログ・メッセージのローテーションを実施しないことも選択できます。この場合は、すべてのメッセージが単一のファイルに蓄積され、ファイル・サイズが大きくなり過ぎたときにはその中身を削除する必要があります。
ログ・ファイルが特定のサイズに達したときに古いメッセージをローテーションすることを選択した場合は、最小限のファイル・サイズを指定する必要があります。ログ・ファイルが指定の最小サイズに到達すると、サーバーが次回ファイル・サイズをチェックする際に、現在のログ・ファイルの名前が変更され、それ以降のメッセージを保存するための新規ログ・ファイルが作成されます。
定期的な間隔で古いメッセージをローテーションすることを選択した場合は、最初の新しいログ・ファイルが作成された時間と、そのファイルの名前が変更されて置換されるまでの時間間隔を指定する必要があります。
JMSサーバーのログ・ファイルのローテーション設定については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバー・メッセージのログ・ローテーションの構成に関する項を参照してください。
ローテーションされたログ・ファイルは、作成順に番号付けされます。たとえば、7番目にローテーションされたファイルはmyserver.log00007という名前になります。トラブルシューティングを容易にするため、ログ・ファイルの名前を変更したり、ログ・ファイルがローテーションされた日時を含めたりできます。これを行うには、ファイル名にjava.text.SimpleDateFormat変数を追加します。それぞれの変数はパーセント記号(%)で囲みます。ログ・ファイルの名前の変更時に相対パス名を指定した場合、サーバーのルート・ディレクトリが基準と解釈されます。
JMSサーバーのメッセージ・ログ・ファイルの名前の変更については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバー・メッセージのログ・ローテーションの構成に関する項を参照してください。
古いログ・ファイルをファイル・サイズまたは時間間隔に基づいてローテーションする場合は、古いメッセージの格納のためにJMSサーバーが作成するログ・ファイルの数を制限することもできます。この制限に達すると、最も古いログ・ファイルが削除され、最新の接尾辞の付いた新しいログ・ファイルが作成されます。このオプションを有効にしない場合は新しいファイルが無限に作成されていくため、必要に応じてこれらのファイルを手動で削除する必要があります。
JMSサーバーのメッセージ・ログ・ファイルの数の制限については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバー・メッセージのログ・ローテーションの構成に関する項を参照してください。
WebLogic JMS構成および実行時APIを使用すると、メッセージの生成、挿入、および消費の処理を休止したり再開したりできます。休止および再開が可能なのは、JMS宛先または一時的な宛先、同じテンプレートを使用して構成された宛先のグループ、および単一のJMSサーバーによってホストされるすべての宛先において、プログラム的に(JMXや実行時MBean APIを使用して)または管理上の理由で(管理コンソールを使用して)実行されるメッセージ処理です。外部リソースに障害が発生したとき、JMSサブシステムがメッセージの受け付けと配信(および再配信)を継続すると、システムに過度の負荷がかかることがあります。しかし、メッセージ処理を休止(および再開)することで、外部リソースの障害発生時のJMSサブシステムの動作を制御できます。
JMSサーバーおよび「休止」状態にあるその宛先を起動すると、それらの宛先でのメッセージの生成、挿入、または消費が起動後直ちに休止します。その後管理者が休止している宛先の状態を「再開」に変更すると、通常のメッセージ処理アクティビティ(生成、挿入、または消費)が再開します。また、新しい実行時オプションを使用すると、実行中の宛先の現在の状態を変更して、新しいメッセージの生成、挿入、または消費を許可または禁止できます。
宛先では、メッセージに対して様々な処理が実行されます。
プロデューサが新しいメッセージを作成して宛先に送信すると、メッセージが生成されます。
処理中の作業が完了すると、メッセージが挿入されます。処理中の作業の完了とは、トランザクションのコミットにおいてメッセージが使用可能になったときや、宛先において遅延が使用可能になった後にメッセージが使用可能になるようにスケジューリングされたときです。
メッセージが宛先から削除されると、そのメッセージが消費されます。
以下のセクションで説明するように、起動時または実行時にこれらの処理のいずれかまたはすべてを休止および再開できます。
JMS宛先での「生成が休止」されると、その宛先にアタッチされている新しいプロデューサと既存のプロデューサにおいて、その宛先に対する新しいメッセージを生成できなくなります。休止している宛先に対してプロデューサがメッセージを送信しようとすると、宛先が休止していることを示す例外が返されます。宛先で「休止していた生成が再開」されると、新しいメッセージの生成が再び許可されます。メッセージの生成の休止では、処理中の作業の結果であるメッセージの挿入は休止されません。
起動時には、JMSサーバーのすべての宛先、同じJMSテンプレートを指す宛先のグループ、または個別の宛先での生成を休止または再開できます。production-paused-at-startupを構成した場合は、指定した宛先でのメッセージの生成アクティビティが次回のサーバー起動時に禁止され、その宛先の状態を明示的に「生成が有効化された」状態に変更するまで継続します。生成の再開を構成した場合は、指定した宛先でのメッセージの生成アクティビティが次回のサーバー起動時に許可され、その宛先の状態を明示的に「生成の休止」状態に変更するまで継続します。
管理コンソールを使用して起動時にメッセージの生成を休止および再開する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。
「共通分散キュー - サーバー再起動時のメッセージ処理の休止」
|
注意: この処理はレベル(JMSサーバー・レベル、JMSテンプレート・レベル、スタンドアロンの宛先レベル、共通分散宛先レベルなど)ごとに構成できるため、レベル間での優先順位が確立されています。詳細については、「起動時のメッセージ処理の休止と再開の優先順位」を参照してください。 |
実行時には、JMSサーバーでターゲット指定されているすべての宛先、同じJMSテンプレートを指す宛先のグループ、または個別の宛先での生成を休止または再開できます。構成の変更がどのレベル(JMSサーバー・レベル、JMSテンプレート・レベル、または宛先レベル)で行われたかに関係なく、最も新しく変更された構成が常に優先されます。
実行時にメッセージの生成を休止および再開する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。
メンバー宛先での生成が休止されると、プロデューサによる生成においてそのメンバー宛先が考慮されなくなります。メッセージは、生成が可能な他のメンバー宛先に向けて送信されます。
JMS接続を停止または開始しても、宛先の生成休止状態や生成再開状態には影響しません。
JMS宛先での「挿入」が休止されると、処理中の作業の結果として挿入されるメッセージと、プロデューサによって送信された新しいメッセージの両方が、宛先に現れなくなります。すべてのメッセージが宛先に現れないようにするには、挿入の休止を使用します。
処理中の作業が保留になっているかどうかを特定するには、管理コンソールの統計を調べます。宛先でのメッセージの「挿入」を休止すると、処理中の作業完了に関係するメッセージが「配信不可」になり、新しいメッセージの生成処理が失敗します。コンシューマではこれらのメッセージがすべて「認識不可」になり、保留中でなくなったメッセージを反映するため統計が調整されます。
「挿入」の休止処理は、「生成」の休止処理よりも優先されます。つまり、宛先が現在「生成の休止」状態にある場合は、「挿入の休止」状態に変更できます。
処理中のメッセージが宛先に現れるようにするには、その宛先でのメッセージの挿入を明示的に「再開」する必要があります。挿入の「再開」処理が正常に完了すると、宛先が「挿入が有効化された」状態になり、「認識不可」だった処理中のメッセージがすべて認識可能になります。
起動時には、JMSサーバーのすべての宛先、同じJMSテンプレートを指す宛先のグループ、または個別の宛先での挿入を休止または再開できます。insertion-paused-at-startupを構成した場合は、指定した宛先でのメッセージの挿入および生成アクティビティが次回のサーバー起動時に禁止され、その宛先の状態を明示的に「挿入が有効化された」状態に変更するまで継続します。挿入の再開を構成した場合は、指定した宛先でのメッセージの挿入アクティビティが次回のサーバー起動時に許可され、その宛先の状態を明示的に「挿入の休止」状態に変更するまで継続します。
起動時のメッセージ挿入の休止と再開の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。
「共通分散キュー - サーバー再起動時のメッセージ処理の休止」
|
注意: この処理はレベル(JMSサーバー・レベル、JMSテンプレート・レベル、宛先レベルなど)ごとに構成できるため、レベル間での優先順位が確立されています。詳細については、「起動時のメッセージ処理の休止と再開の優先順位」を参照してください。 |
実行時には、JMSサーバーのすべての宛先、同じJMSテンプレートを指す宛先のグループ、または個別の宛先での挿入を休止または再開できます。構成の変更がどのレベル(JMSサーバー・レベル、JMSテンプレート・レベル、または宛先レベル)で行われたかに関係なく、最も新しく変更された構成が常に優先されます。
実行時にメッセージ挿入を休止および再開する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。
JMS宛先での「消費が休止」されると、その宛先のメッセージが消費できなくなります。宛先が「消費の休止から再開」されると、その宛先にアタッチされている新しいコンシューマと既存のコンシューマが、その宛先のメッセージを再び消費できるようになります。
宛先での消費が休止されると、宛先の状態が「消費の休止」とマークされ、消費が再開されてメッセージが消費可能になるまで、すべての新しい同期受信処理がブロックされます。ブロッキング・タイムアウト処理を伴うすべての同期受信は、指定した時間の間ブロックされます。宛先での消費が休止している間は、その宛先にアタッチされている同期コンシューマへのメッセージは配信されません。
消費の「休止」処理が正常に行われた後、その宛先で消費処理を行えるようにするには、ユーザーが宛先を明示的に「再開」する必要があります。
起動時には、JMSサーバーのすべての宛先、同じJMSテンプレートを指す宛先のグループ、または個別の宛先での消費を休止または再開できます。consumption-paused-at-startupを構成した場合は、指定した宛先のメッセージの消費アクティビティが次回のサーバー起動時に禁止され、その宛先の状態を明示的に「消費が有効化された」状態に変更するまで継続します。消費の再開を構成した場合は、指定した宛先でのメッセージ消費アクティビティが次回のサーバー起動時に許可され、その宛先の状態を明示的に「消費の休止」状態に変更するまで継続します。
起動時に消費を休止および再開する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。
実行時には、JMSサーバーのすべての宛先、同じJMSテンプレートを指す宛先のグループ、または個別の宛先での消費を休止または再開できます。構成の変更がどのレベル(JMSサーバー・レベル、JMSテンプレート・レベル、または宛先レベル)で行われたかに関係なく、最も新しく変更された構成が常に優先されます。
実行時に消費を休止および再開する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。
キュー・ブラウザは、キュー宛先の「参照」のみが可能な特殊なタイプのコンシューマです。消費が休止されている宛先でも参照処理は禁止されません。
消費が休止されているメンバー宛先は、コンシューマのロード・バランシング・アルゴリズムでは考慮されません。
宛先での消費を休止すると、メッセージドリブンBean (MDB)が関連する宛先からのメッセージを取得できなくなります。この機能を使用すると、接続の開始/停止を使用する場合と比較して、より柔軟に個別の宛先レベルからのMDBへのメッセージの配信を制御できます。つまり、消費の休止/再開機能を使用すると、JMS接続を複数のMDBで共有している場合でも、関連付けられた宛先での消費を休止することによって、特定のMDBへのメッセージの配信を禁止できるということです。
MDBの使用の詳細は、『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』のJMSリソース停止中のメッセージ配信の中断の構成に関する項を参照してください。
JMS接続の停止/開始機能では、コンシューマが受信APIを正常に呼び出したかどうかが判別されます。宛先での消費の休止/再開機能では、受信呼出しにおいて宛先からメッセージを取得したかどうかが判別されます。コンシューマの接続を停止または開始しても、宛先の消費の休止状態には影響しません。
宛先での消費が休止されている場合、コンシューマの接続が「停止」状態から「開始」に変更されると、同期受信処理がブロックされるかタイムアウトします。非同期コンシューマが関連付けられている宛先が「消費の休止」状態にあると、非同期コンシューマはメッセージを受信しません。
メッセージ・プロデューサに関連付けられた処理中の作業の結果として、宛先において以下の種類のメッセージが挿入されます。
未生成のメッセージ - TimeToDeliverに設定された時間にプロデューサによって将来作成されることになっているメッセージ。未生成メッセージは、配信されるまでは宛先の統計で「保留中」のメッセージとしてカウントされ、消費することができません。
未コミット・メッセージ - ユーザー・トランザクションまたはトランザクション・セッションを使用してトランザクションの一環として生成されたメッセージのうち、まだコミットまたはロールバックされていないメッセージ。未コミット・メッセージは、トランザクションが完了するまでは宛先の統計で「保留中」のメッセージとしてカウントされ、消費することができません。
送信をブロックする割当て - 割当て制限のために初回には宛先に到達できなかった場合に、宛先が使用可能になるのを待機して一定時間ブロックするメッセージ。メッセージは宛先において、メッセージ割当て制限、バイト割当て制限、またはその両方を超える可能性があります。ブロック中にはこうしたメッセージはシステムから認識できないため、宛先の統計では一切カウントされません。
メッセージ・コンシューマに関連付けられた処理中の作業の結果として、宛先において以下の種類のメッセージが挿入されます。
未応答(CLIENT ACK PENDING)メッセージ - クライアントによって受信されており、クライアントからの応答を待機しているメッセージ。この種のメッセージは「保留中のメッセージ」であり、確認応答を受信したときに宛先/システムから削除されます。
未コミット・メッセージ - クライアントによってトランザクション内で受信されているメッセージのうち、まだコミットまたはロールバックされていないメッセージ。この種のメッセージは、クライアントがそのトランザクションを正常にコミットしたときに、システムから削除されます。
ロールバック・メッセージ - トランザクションが正常にロールバックされたために、宛先に戻されたメッセージ。
これらのメッセージは、関連する接続ファクトリ上で構成された再配信パラメータ(RedeliveryDelayおよび/またはRedeliveryDelayOverrideおよびRedeliveryLimitなど)や、ロールバック・リクエストが内部で非同期的に処理されるかに応じて、クライアントに対してただちに再配信できるかどうかが決まります。その結果、ロールバック・リクエスト後に呼出しがただちに実行される場合、ロールバック・リクエストへの消費処理件名に関連するメッセージは、コンシューマreceiveNoWait()呼出しに表示できなくなります。
再配信遅延が構成されている場合、メッセージはその遅延の期間は再配信不可となり、宛先の統計では「保留中」のメッセージとしてカウントされます。遅延期間の後、再配信制限を超えていなければ、メッセージが配信されて宛先の統計で「現在の」メッセージとしてカウントされます。再配信制限を超えている場合は、エラー配信先が構成されていればそこにメッセージが移動し、エラー配信先が構成されていなければメッセージは破棄されます。
ロールバックは、メッセージが処理される順序に影響を及ぼす可能性があります。ロールバックされたメッセージは、同一のキューまたはサブスクリプション内の後続のメッセージが処理された後で再配信されます。メッセージの順序付けを厳密に行う必要がある場合、『Oracle WebLogic Server JMSのプログラミング』のメッセージの順序単位の使用に関する項を参照してください。
回復されたメッセージ - クライアントによるセッション「回復」の呼出しが明示的に行われたためにキューに現れるメッセージ。このメッセージは、前述のロールバックされたメッセージとほぼ同じです。
再配信されたメッセージ - クライアントへの配信に失敗したために宛先に再び現れるメッセージ。このメッセージは、前述のロールバックされたメッセージとほぼ同じです。
起動時に、宛先の休止や再開を様々なレベルの属性で設定できます。
JMSサーバーを使用して宛先のグループをホストしている場合は、宛先のグループ全体でのメッセージ処理を休止または再開できる
JMSテンプレートを使用して宛先のグループの属性値を定義している場合は、グループ内のすべての宛先でのメッセージ処理を休止または再開できる
単一の宛先でのメッセージ処理を休止または再開できる
これらの各レベルの値が起動時に一致していない場合、指定した宛先でのメッセージ処理は以下の優先順位に基づいて決定されます。メッセージ処理の休止および再開を構成するための各属性において、
宛先をホストするJMSサーバーの属性セットに有効な値が設定されている場合は、その値に基づいて起動時の宛先の状態が決定されます。サーバー・レベルの設定が最も優先されます。
宛先をホストするJMSサーバーの属性セットに有効な値が設定されていない場合は、宛先レベルの属性の値が2番目に優先され、その値に基づいて起動時の宛先の状態が決定されます。
宛先をホストするJMSサーバーおよび宛先の属性セットに有効な値が設定されていない場合は、JMSテンプレートの属性の値に基づいて起動時の宛先の状態が決定されます。
これら3つのレベルのすべてで属性が設定されていない場合は、値が「false」に設定されているものと見なされます。
管理ユーザーや管理グループは、その時点で宛先の状態が他のユーザーによって制御されているかどうかに関係なく、宛先の現在の状態をオーバーライドできます。
2人の非管理ユーザーが宛先の状態を制御しようとした場合、以下の規則が適用されます。
宛先の状態を「休止」に変更したユーザーと同じグループに属すユーザーのみが、その宛先を「再開」して通常の処理に戻すことができます。
所属の異なる2ユーザーによって状態の変更が試行された場合
