| Oracle® Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理 11g リリース 1 (10.3.1) B55547-01 |
|
 戻る |
| Oracle® Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理 11g リリース 1 (10.3.1) B55547-01 |
|
戻る |
WebLogic Server のこのリリースには WebLogic 診断サービスが含まれています。これは、WebLogic Server プロセス内で実行され、標準のサーバ ライフ サイクルに参加する、モニタと診断のサービスです。このサービスを使用すると、実行中のサーバおよびそのコンテナ内にデプロイされているアプリケーションによって生成された診断データを作成、収集、分析、アーカイブし、それらの診断データにアクセスできます。このデータを基に、サーバおよびアプリケーションの実行時パフォーマンスを把握できます。また、障害発生時に、このデータを使用して、障害を隔離および診断できます。WebLogic JMS ではこのサービスを利用して、実行時の統計、キューやトピックに送信される通知、メッセージ ライフ サイクルのロギング、およびデバッグの機能を拡張し、WebLogic ドメインが円滑に実行され続けるよう支援します。
JMS の統計のモニタと JMS メッセージの管理の詳細については、「JMS 統計のモニタとメッセージの管理」を参照してください。
以下の節では、WebLogic JMS メッセージおよびコンフィグレーションのトラブルシューティングの方法について説明します。
「通知」は、監視ルールの評価が true となった場合にトリガされるアクションです。JMS 通知は、関連する監視のトリガに応じて JMS トピックまたは JMS キューにメッセージをポストするために使用します。システム リソース コンフィグレーション ファイルの <destination-jndi-name> 要素と <connection-factory-jndi-name> 要素で、メッセージの配信方法を定義します。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server 診断フレームワークのコンフィグレーションと使い方』の「通知のコンフィグレーション」を参照してください。
特定のアプリケーションに問題があると突き止めたら、WebLogic Server のデバッグ機能をアクティブ化して、アプリケーション内の特定の問題を探し当てることができます。
デバッグは、適切な ServerDebug コンフィグレーション属性を true に設定することで有効化できます。必要に応じて、サーバの StdoutSeverity を Debug に設定することもできます。
コンフィグレーション属性は、以下のいずれかの方法で変更できます。
コマンドラインで適切なプロパティを設定します。次に例を示します。
-Dweblogic.debug.DebugJMSBackEnd=true -Dweblogic.log.StdoutSeverity="Debug"
この方法は静的なものであり、サーバの起動時にのみ使用できます。
WebLogic Server Administration Console を使用して、デバッグ値を設定します。
まだ行っていない場合、Administration Console のチェンジ センタで [ロックして編集] をクリックします (『Oracle Fusion Middleware Oracle WebLogic Server の紹介』の「チェンジ センタの使用」を参照)。
Administration Console の左ペインで、[環境] を展開して [サーバ] を選択します。
[サーバの概要] ページで、デバッグを有効化または無効化するサーバをクリックして、そのサーバの設定ページを開きます。
[デバッグ] をクリックします。
[デフォルト] を展開します。
変更するデバッグ スコープまたは属性のチェック ボックスを選択します。
[有効化] (または [無効化]) を選択して、チェックを入れたデバッグ スコープまたは属性を有効化 (または無効化) します。
Administration Console のチェンジ センタで [変更のアクティブ化] をクリックしてこれらの変更をアクティブ化します。
すべての変更が即座に有効になるわけではありません。再起動が必要な場合もあります (『Oracle Fusion Middleware 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 の使用は動的な手法で、サーバの実行中にデバッグを有効化するために使用できます。
java weblogic.diagnostics.debug.DebugScopeViewer を使うと DebugScope 定義をツリー表示できます。
以下に示す JMS 用の登録済みデバッグ スコープを有効化できます。
DebugJMSBackEnd (スコープは weblogic.jms.backend) - JMS バック エンドのデバッグ情報 (分散送り先や JMS SAF 用に使用される情報を含む) を出力します。
DebugJMSFrontEnd (スコープは weblogic.jms.frontend) - JMS フロント エンドのデバッグ情報 (マルチキャスト用に使用される情報を含む) を出力します。
DebugJMSCommon (スコープは weblogic.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 サブシステムを介して個々の (通常は「仕分けされた」) アプリケーション リクエストのフローを追跡する方法があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server 診断フレームワークのコンフィグレーションと使い方』の「DyeInjection モニタを介した仕分けベクトルのコンフィグレーション」を参照してください。
JMS ロギングは、JMS サーバを作成するとデフォルトで有効になります。しかし、この JMS サーバに対象指定する JMS モジュールのメッセージ送り先 (または送り先で使用する JMS テンプレート) では、JMS ロギングを明示的に有効にする必要があります。WebLogic ロギング サービスの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ログ ファイルのコンフィグレーションとログ メッセージのフィルタ処理』の「WebLogic ロギング サービスについて」を参照してください。
メッセージのライフ サイクルとは、JMS メッセージが JMS サーバに届いた後、JMS API または JMS メッセージ管理 API を通じて、そのメッセージに順に発生するイベントを外側から見た概念です。メッセージ ライフ サイクルのロギングを利用することで、JMS サーバから見た JMS メッセージの存在やステータスに関する情報に容易にアクセスできます。各メッセージ ログには、メッセージの生成、消費、削除などの基本的なライフ サイクル イベントについての情報が含まれます。
ロギングは、長期間にわたって継続的に発生します。また、JMS サーバの実行中にリアルタイム モードで使用したり、JMS サーバの停止中にオフライン形式で使用したりすることも可能です。メッセージ ロギングのコンフィグレーションの詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプにある以下のトピックを参照してください。
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 つのメッセージについて 1 回のみです。メッセージを受信したトピック サブスクライバごとに別々に期限切れイベントが発生しても、イベントが複数回ログに記録されることはありません。
再試行超過 - このイベントは、メッセージが再配信の再試行制限を超えたときにログに記録されます。トピック サブスクライバごとに再配信回数が異なる場合は、このイベントが 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 Administration Console を使用して有効にしたり無効にしたりできます。詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプにある以下のトピックを参照してください。
WebLogic Java Management Extensions (JMX) を使用すると、JMS メッセージ ログを管理するための JMSSystemResourceMBean および JMSRuntimeMBean の MBean にアクセスできます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JMX によるカスタム管理ユーティリティの開発』の「WebLogic Server サブシステム MBean の概要」を参照してください。
JMS サーバおよび JMS システム リソースの JMS メッセージ ロギングは、WebLogic Scripting Tool を使用してコンフィグレーションすることもできます。詳細については、「WLST を使用した JMS サーバと JMS システム モジュール リソースの管理」を参照してください。
メッセージ ロギングを有効にする際は、メッセージ ヘッダ フィールド、システム定義のメッセージ プロパティ、およびユーザ定義のプロパティのそれぞれについて、ログ エントリにそのすべてを含めるか一部のみを含めるかを指定できます。また、メッセージの本文を含めるかどうかも選択できます。メッセージのヘッダおよびプロパティの詳細については、『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JMS サーバ メッセージのログ ローテーションのコンフィグレーション」を参照してください。
ローテーションされたログ ファイルは、作成順に番号付けされます。たとえば、7 番目にローテーションされたファイルは myserver.log00007 という名前になります。トラブルシューティングを容易にするため、ログ ファイルの名前を変更したり、ログ ファイルがローテーションされた日時を含めたりできます。ログ ファイル名に日時を含めるには、ファイル名に java.text.SimpleDateFormat 変数を追加します。それぞれの変数はパーセント記号 (%) で囲みます。ログ ファイルの名前の変更時に相対パス名を指定した場合、サーバのルート ディレクトリが基準と解釈されます。
JMS サーバのメッセージ ログ ファイルの名前の変更については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JMS サーバ メッセージのログ ローテーションのコンフィグレーション」を参照してください。
古いログ ファイルをファイル サイズまたは時間間隔に基づいてローテーションする場合は、古いメッセージの格納のために JMS サーバが作成するログ ファイルの数を制限することもできます。この制限に達すると、最も古いログ ファイルが削除され、最新のサフィックスの付いた新しいログ ファイルが作成されます。このオプションを有効にしない場合は新しいファイルが無限に作成されていくため、必要に応じてこれらのファイルを手動で削除する必要があります。
JMS サーバのメッセージ ログ ファイル数の制限については、Oracle Fusion Middleware Oracle WebLogic Server の 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 を使用して起動時にメッセージの生成を休止および再開する方法については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの以下のトピックを参照してください。
「サーバ再起動時の JMS テンプレート メッセージ処理の休止」
「共通分散キュー - サーバ再起動時のメッセージ処理の休止」
|
注意 : この処理はレベル (JMS サーバ レベル、JMS テンプレート レベル、スタンドアロンの送り先レベル、共通分散送り先レベルなど) ごとにコンフィグレーションできるため、レベル間での優先順位が確立されています。詳細については、「起動時のメッセージ処理の休止と再開の優先順位」を参照してください。 |
実行時には、JMS サーバで対象指定されているすべての送り先、同じ JMS テンプレートを指す送り先のグループ、または個別の送り先での生成を休止または再開できます。コンフィグレーションの変更がどのレベル (JMS サーバ レベル、JMS テンプレート レベル、または送り先レベル) で行われたかに関係なく、最も新しく変更されたコンフィグレーションが常に優先されます。
実行時の生成の休止と再開の詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの以下のトピックを参照してください。
メンバー送り先での生成が休止されると、プロデューサによる生成においてそのメンバー送り先が考慮されなくなります。メッセージは、生成が可能な他のメンバー送り先に向けて送信されます。
JMS 接続を停止または開始しても、送り先の生成休止状態や生成再開状態には影響しません。
JMS 送り先での「挿入」が休止されると、処理中の作業の結果として挿入されるメッセージと、プロデューサによって送信された新しいメッセージの両方が、送り先に現れなくなります。すべてのメッセージが送り先に現れないようにするには、挿入の休止を使用します。
処理中の作業が保留になっているかどうかを特定するには、Administration Console の統計を調べます。送り先でのメッセージの「挿入」を休止すると、処理中の作業完了に関係するメッセージが「配信不可」になり、新しいメッセージの生成処理が失敗します。コンシューマではこれらのメッセージがすべて「認識不可」になり、保留中でなくなったメッセージを反映するため統計が調整されます。
「挿入」の休止処理は、「生成」の休止処理よりも優先されます。つまり、送り先が現在「生成の休止」状態にある場合は、「挿入の休止」状態に変更できます。
処理中のメッセージが送り先に現れるようにするには、その送り先でのメッセージの挿入を明示的に「再開」する必要があります。挿入の「再開」処理が正常に完了すると、送り先が「挿入が有効化された」状態になり、「認識不可」だった処理中のメッセージがすべて認識可能になります。
起動時には、JMS サーバのすべての送り先、同じ JMS テンプレートを指す送り先のグループ、または個別の送り先での挿入を休止または再開できます。insertion-paused-at-startup をコンフィグレーションした場合は、指定した送り先でのメッセージの挿入および生成アクティビティが次回のサーバ起動時に禁止され、その送り先の状態を明示的に「挿入が有効化された」状態に変更するまで継続します。挿入の再開をコンフィグレーションした場合は、指定した送り先でのメッセージの挿入アクティビティが次回のサーバ起動時に許可され、その送り先の状態を明示的に「挿入の休止」状態に変更するまで継続します。
起動時のメッセージ挿入の休止と再開の詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの以下のトピックを参照してください。
「共通分散キュー - サーバ再起動時のメッセージ処理の休止」
|
注意 : この処理はレベル (JMS サーバ レベル、JMS テンプレート レベル、送り先レベルなど) ごとにコンフィグレーションできるため、レベル間での優先順位が確立されています。詳細については、「起動時のメッセージ処理の休止と再開の優先順位」を参照してください。 |
実行時には、JMS サーバのすべての送り先、同じ JMS テンプレートを指す送り先のグループ、または個別の送り先での挿入を休止または再開できます。コンフィグレーションの変更がどのレベル (JMS サーバ レベル、JMS テンプレート レベル、または送り先レベル) で行われたかに関係なく、最も新しく変更されたコンフィグレーションが常に優先されます。
実行時の挿入の休止と再開の詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの以下のトピックを参照してください。
メンバー送り先での挿入が休止されると、メッセージの転送においてそのメンバー送り先が考慮されなくなります。メッセージは、挿入が可能な他のメンバー送り先に向けて送信されます。
JMS 送り先での「消費が休止」されると、その送り先のメッセージが消費できなくなります。JMS 送り先での「消費の休止が再開」されると、その送り先にアタッチされている新しいコンシューマと既存のコンシューマが、その送り先のメッセージを消費できるようになります。
送り先での消費が休止されると、送り先の状態が「消費の休止」とマークされ、消費が再開されてメッセージが消費可能になるまで、すべての新しい同期受信処理がブロックされます。ブロッキング タイムアウト処理を伴うすべての同期受信は、指定した時間の間ブロックされます。送り先での消費が休止している間は、その送り先にアタッチされている同期コンシューマへのメッセージは配信されません。
消費の「休止」処理が正常に行われた後、その送り先で消費処理を行えるようにするには、ユーザが送り先を明示的に「再開」する必要があります。
起動時には、JMS サーバのすべての送り先、同じ JMS テンプレートを指す送り先のグループ、または個別の送り先での消費を休止または再開できます。consumption-paused-at-startup をコンフィグレーションした場合は、指定した送り先のメッセージの消費アクティビティが次回のサーバ起動時に禁止され、その送り先の状態を明示的に「消費が有効化された」状態に変更するまで継続します。消費の再開をコンフィグレーションした場合は、指定した送り先でのメッセージ消費アクティビティが次回のサーバ起動時に許可され、その送り先の状態を明示的に「消費の休止」状態に変更するまで継続します。
起動時の消費の休止と再開の詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの以下のトピックを参照してください。
実行時には、JMS サーバのすべての送り先、同じ JMS テンプレートを指す送り先のグループ、または個別の送り先での消費を休止または再開できます。コンフィグレーションの変更がどのレベル (JMS サーバ レベル、JMS テンプレート レベル、または送り先レベル) で行われたかに関係なく、最も新しく変更されたコンフィグレーションが常に優先されます。
実行時の消費の休止と再開の詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの以下のトピックを参照してください。
キュー ブラウザは、キュー送り先の「参照」のみが可能な特殊なタイプのコンシューマです。消費が休止されている送り先でも参照処理は禁止されません。
消費が休止されているメンバー送り先は、コンシューマのロード バランシング アルゴリズムでは考慮されません。
送り先での消費を休止すると、メッセージ駆動型 Bean (MDB) が関連する送り先からのメッセージを取得できなくなります。この機能を使用すると、接続の開始/停止を使用する場合と比較して、より柔軟に個別の送り先レベルからの MDB へのメッセージの配信を制御できます。つまり、消費の休止/再開機能を使用すると、JMS 接続を複数の MDB で共有している場合でも、関連付けられた送り先での消費を休止することによって、特定の MDB へのメッセージの配信を禁止できるということです。
MDB の使用の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「JMS リソース停止中のメッセージ配信の中断のコンフィグレーション」を参照してください。
JMS 接続の停止/開始機能では、コンシューマが受信 API を正常に呼び出したかどうかが判別されます。送り先での消費の休止/再開機能では、受信呼び出しにおいて送り先からメッセージを取得したかどうかが判別されます。コンシューマの接続を停止または開始しても、送り先の消費の休止状態には影響しません。
送り先での消費が休止されている場合、コンシューマの接続が「停止」状態から「開始」に変更されると、同期受信処理がブロックされるかタイムアウトします。非同期コンシューマが関連付けられている送り先が「消費の休止」状態にあると、非同期コンシューマはメッセージを受信しません。
メッセージ プロデューサに関連付けられた処理中の作業の結果として、送り先において以下の種類のメッセージが挿入されます。
未生成のメッセージ - TimeToDeliver に設定された時間にプロデューサによって将来作成されることになっているメッセージ。未生成メッセージは、配信されるまでは送り先の統計で「保留中」のメッセージとしてカウントされ、消費することができません。
未コミット メッセージ - ユーザ トランザクションまたはトランザクション セッションを使用してトランザクションの一環として生成されたメッセージのうち、まだコミットまたはロールバックされていないメッセージ。未コミット メッセージは、トランザクションが完了するまでは送り先の統計で「保留中」のメッセージとしてカウントされ、消費することができません。
送信をブロックする割り当て - 割り当て制限のために初回には送り先に到達できなかった場合に、送り先が使用可能になるのを待機して一定時間ブロックするメッセージ。メッセージは送り先において、メッセージ割り当て制限、バイト割り当て制限、またはその両方を超える可能性があります。ブロック中にはこうしたメッセージはシステムから認識できないため、送り先の統計では一切カウントされません。
メッセージ コンシューマに関連付けられた処理中の作業の結果として、送り先において以下の種類のメッセージが挿入されます。
未応答 (CLIENT ACK PENDING) メッセージ - クライアントによって受信されており、クライアントからの応答を待機しているメッセージ。この種のメッセージは「保留中のメッセージ」であり、確認応答を受信したときに送り先/システムから削除されます。
未コミット メッセージ - クライアントによってトランザクション内で受信されているメッセージのうち、まだコミットまたはロールバックされていないメッセージ。この種のメッセージは、クライアントがそのトランザクションを正常にコミットしたときに、システムから削除されます。
ロールバック メッセージ - トランザクションが正常にロールバックされたために、送り先に戻されたメッセージ。
この種のメッセージは、クライアントに対して直ちに再配信可能になる場合とならない場合があります。これは、関連付けられている接続ファクトリおよび送り先においてコンフィグレーションされている再配信パラメータ (RedeliveryDelay、RedeliveryDelayOverride、RedeliveryLimit など) に依存します。
再配信遅延がコンフィグレーションされている場合、メッセージはその遅延の期間は再配信不可となり、送り先の統計では「保留中」のメッセージとしてカウントされます。遅延期間の後、再配信制限を超えていなければ、メッセージが配信されて送り先の統計で「現在の」メッセージとしてカウントされます。再配信制限を超えている場合は、エラー配信先がコンフィグレーションされていればそこにメッセージが移動し、エラー配信先がコンフィグレーションされていなければメッセージは破棄されます。
回復されたメッセージ - クライアントによるセッション「回復」の呼び出しが明示的に行われたためにキューに現れるメッセージ。このメッセージは、前述のロールバックされたメッセージとほぼ同じです。
再配信されたメッセージ - クライアントへの配信に失敗したために送り先に再び現れるメッセージ。このメッセージは、前述のロールバックされたメッセージとほぼ同じです。
起動時に、送り先の休止や再開をさまざまなレベルの属性で設定できます。
JMS サーバを使用して送り先のグループをホストしている場合は、送り先のグループ全体でのメッセージ処理を休止または再開できる
JMS テンプレートを使用して送り先のグループの属性値を定義している場合は、グループ内のすべての送り先でのメッセージ処理を休止または再開できる
単一の送り先でのメッセージ処理を休止または再開できる
これらの各レベルの値が起動時に一致していない場合、指定した送り先でのメッセージ処理は以下の優先順位に基づいて決定されます。メッセージ処理の休止および再開をコンフィグレーションするための各属性において、
送り先をホストする JMS サーバの属性セットに有効な値が設定されている場合は、その値に基づいて起動時の送り先の状態が決定されます。サーバ レベルの設定が最も優先されます。
送り先をホストする JMS サーバの属性セットに有効な値が設定されていない場合は、送り先レベルの属性の値が 2 番目に優先され、その値に基づいて起動時の送り先の状態が決定されます。
送り先をホストする JMS サーバおよび送り先の属性セットに有効な値が設定されていない場合は、JMS テンプレートの属性の値に基づいて起動時の送り先の状態が決定されます。
これら 3 つのレベルのすべてで属性が設定されていない場合は、値が「false」に設定されているものと見なされます。
管理ユーザや管理グループは、その時点で送り先の状態が他のユーザによって制御されているかどうかに関係なく、送り先の現在の状態をオーバーライドできます。
2 人の非管理ユーザが送り先の状態を制御しようとした場合、以下の規則が適用されます。
送り先の状態を「休止」に変更したユーザと同じグループに属すユーザのみが、その送り先を「再開」して通常の処理に戻すことができます。
所属の異なる 2 ユーザによって状態の変更が試行された場合
