Oracle® Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理 11g リリース1(10.3.5) B60991-03 |
|
前 |
次 |
WebLogic Serverインスタンスが遷移できる一連の状態の変遷のことを、サーバーのライフサイクルといいます。WebLogic Serverインスタンスは常に、特定の動作状態にあります。起動、停止、中断などのコマンドは、サーバー・インスタンスの動作状態に所定の変化をもたらします。次の項では、WebLogic Serverの状態、状態の遷移、およびライフサイクル・コマンドについて説明します。
図5-1は、サーバーのライフサイクル、および状態とライフサイクル・コマンドの間の関係を示しています。
各状態と、状態間の関係を理解するには、「サーバー・ライフサイクルにおけるサーバーの状態について」を参照してください。ライフサイクル・コマンドについては、「サーバーのライフサイクル・コマンドの使用について」を参照してください。
WebLogic Serverは、サーバー・インスタンスの現在の状態、およびサーバー・インスタンスが起動してからこれまでに起こった状態の遷移に関する情報を表示および保存します。この情報は、以下の作業を行う管理者にとって便利です。
サーバー・インスタンスとそれがホストするアプリケーションの可用性をモニターする
起動や停止などの日常のタスクを行う
アプリケーション・サービスの問題を診断する
サーバー・インスタンスで障害やクラッシュが発生したときに、サービスの移行などの修正アクションを計画する
サーバーの状態を取得する方法は、次のとおりです。
管理コンソール - 以下の複数のページで状態情報が表示されます。
「サーバーのサマリー」ページ(「環境」>「サーバー」)で、「サーバー」表に、現在のドメインの各サーバー・インスタンスの現在の状態が表示されます。
「SERVER_NAME」
>「監視」ページには、現在実行されているサーバー・インスタンスの状態、およびその状態になった日付と時刻が表示されます。
「診断」>「ログ・ファイル」には、サーバー・インスタンスが最後に起動してからこれまでに起こった状態遷移のタイムスタンプ付きメッセージが格納されています。
プログラム: サーバーのweblogic.management.runtime.ServerRuntimeMBean
のgetState()
メソッドを使用します。たとえば、時間のかかる正常な停止プロセスの進捗をモニターするには、独立したスレッドでgetstate
を発行します。詳細は、Oracle WebLogic Server MBeanリファレンスのServerRuntimeMBean
を参照してください。
WebLogic Scripting Tool: 『Oracle WebLogic Scripting Tool』の実行時情報の取得に関する項を参照してください。
次の項では、WebLogic Serverのライフサイクルにおける各状態について説明します。
SHUTDOWN
状態のWebLogic Serverインスタンスは、構成されていますが、非アクティブになっています。
サーバー・インスタンスは、停止コマンドまたは強制停止コマンドの結果としてSHUTDOWN
状態になります。また、自動状態モニターの結果として状態が不安定になっていることを検出した場合には、サーバー・インスタンスは自身を強制停止できます。障害の発生を検出した場合に自身を強制停止できるのは、AutoKillIfFailed
属性がtrueに設定されているサーバー・インスタンスのみです。詳細は、「障害が発生したサーバー・インスタンスの自動再起動」を参照してください。
起動コマンド、管理モードで起動コマンド、またはスタンバイ・モードで起動コマンドを使用して、SHUTDOWN
状態のサーバー・インスタンスをSTARTING
状態に遷移できます。
WebLogic Serverインスタンスは、STARTING
状態中に、起動コマンド、管理モードで起動コマンド、またはスタンバイ・モードで起動コマンドの結果としてSHUTDOWN
状態からSTANDBY
状態に遷移します。
STARTING
状態では、サーバー・インスタンスはクライアント・リクエストも管理リクエストも受け付けることができません。
サーバー・インスタンスは以下の方法で構成データを取得します。
管理サーバーは、config
ディレクトリからドメインのセキュリティ構成とその他のドメイン構成データを取得します。
管理対象サーバーは構成データとセキュリティ・データを取得するために管理サーバーにアクセスします。SSL通信を使用するように構成されている場合、管理対象サーバーは、証明書ファイル、キー・ファイルなどの独自のSSL関連ファイルを使用して、残りの構成データとセキュリティ・データを取得するために管理サーバーにアクセスします。
注意: 管理対象サーバーが管理サーバーにアクセスできない場合、デフォルトでは管理対象サーバーは、ローカルにキャッシュされたドメインのconfigディレクトリのコピーを使用して管理対象サーバー独立モードで起動します。「管理対象サーバー独立モードについて」を参照してください。 |
サーバー・インスタンスは、表5-1に示されているサービスを示された順序で起動します。
表5-1 STARTING状態で起動されるサービス
Service | 機能 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
カーネル、実行キュー、サーバー・ランタイムなどの基本的なサービスを含みます。 |
|
管理サーバー専用のサービスのルート。 |
|
ロギングおよびデバッグのコンテナ・サービス。 |
|
サーバー・ステータスの変更をサーバー出力ストリームを介してノード・マネージャに報告する、ノード・マネージャ・サービス。 |
|
|
|
停止時に、管理サーバー接続以外のすべてのRJVMをクローズします。 |
|
|
|
構成されたプロトコルを登録し、それらを発信トラフィックと着信構成で使用可能にします。管理対象サーバーでは、正確なアドレス情報を管理サーバーに提供できるように、起動シーケンスの早い段階でこのサービスが使用可能になっている必要があります。 |
|
このサービスは、構成の一貫性と登録されるプロトコルに依存します。起動シーケンスのこの時点までに、すべてのプロトコルの登録が完了している必要があります。 このサービスの起動後は、 |
|
|
|
|
|
トランザクション・ヘルパーが初期化され、トランザクションをスレッドに関連付けたり、トランザクション・マネージャを取得したり、 起動シーケンスのこの時点では、トランザクション・サービス自体は有効になっていません。 |
|
初期化のみに使用されるRMI起動サービス。 |
|
|
|
VM全体の委任機能をインストールします。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
管理編集サービスを起動します。 |
|
|
|
|
|
|
|
起動シーケンスのこの時点後は、 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
正常な停止時に、保留中のアプリケーション作業をチェックします。アプリケーションもここで停止されます。 |
|
|
|
|
|
|
|
停止時にアプリケーションのトリガーを取り消します。 |
|
プロトコル専用のクライアントのハートビートをサポートします。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
実行時JMXサービス。 |
|
|
|
|
|
|
|
起動クラスと停止クラスの処理を追加します。 |
|
サーバー・ライフサイクル実行時MBeanの作成を処理して、ドメインの制御を行えるようにします。 |
|
サーバーが |
|
STANDBY
状態のサーバー・インスタンスは、通常のリスニング・ポートがクローズされているためリクエストを処理しません。管理ポートはオープンされており、サーバー・インスタンスをRUNNING
状態またはSHUTDOWN
状態に遷移させるライフサイクル・コマンドを受け付けます。それ以外の管理リクエストは受け付けられません。
STANDBY状態で起動したサーバー・インスタンスは、「ホット」バックアップとして待機させておくことができます。ホット・バックアップは高可用性環境で便利な機能です。
サーバー・インスタンスをSTANDBY
状態にし、その状態のままにしておく唯一のライフサイクル・コマンドが、スタンバイ・モードで起動コマンドです。起動コマンドまたは管理モードで起動コマンドを発行すると、サーバー・インスタンスはSTANDBY
状態を経験します。
ADMIN
状態のとき、WebLogic Serverは起動して実行状態にありますが、受け付けるのは管理操作のみとなり、ユーザーはサーバーおよびアプリケーション・レベルの管理タスクを実行できます。ADMIN
状態のサーバー・インスタンスの機能は、以下のとおりです。
管理コンソールが使用できます。
サーバー・インスタンスは、admin
ロールのユーザーからのリクエストを受け付けます。admin
ロールが付与されていないユーザーからのリクエストは拒否されます。
アプリケーションは、アプリケーションのADMIN
状態でアクティブ化されます。アプリケーションは、admin
およびAppTester
ロールのユーザーからのリクエストを受け付けます。アプリケーションのADMIN
状態にあるアプリケーションにアクセスする、これらのロールのユーザーには、管理機能だけでなく、すべてのアプリケーション機能に対するアクセス権があります。
JDBC、JMS、およびJTAの各サブシステムはアクティブであり、それらに対する管理操作を実行できます。ただし、サーバーがADMIN
状態にある場合、これらのサブシステムにアクセスするために管理者レベルの権限を有している必要はありません。
デプロイメントまたは再デプロイメントは許可されます。それらは、サーバー・インスタンスをADMIN
状態からRUNNING
状態に(再開コマンドを使用して)遷移させるときに有効になります。
ClusterService
はアクティブであり、他のクラスタ・メンバーからのハートビートおよび通知をリスニングします。他の管理対象サーバーがクラスタに参加していることを検出できますが、他のクラスタ・メンバーからは認識できません。
管理モードで起動コマンド、中断コマンド、または強制中断コマンドを使用して、サーバー・インスタンスをADMIN
状態に遷移できます。
起動コマンド、停止コマンド、または強制停止コマンドの結果として、サーバー・インスタンスはADMIN
状態を経験します。
ADMIN
状態のサーバー・インスタンスを、再開コマンドを使用してRUNNING
状態に、あるいは停止コマンドまたは強制停止コマンドを使用してSHUTDOWN
状態に遷移できます。
この遷移状態中に、WebLogic ServerはSTANDBY
状態またはADMIN
状態からRUNNING
状態への移動に必要な処理を実行します。
再開コマンドを発行すると、サーバー・インスタンスはRESUMING
状態に遷移します。起動コマンドを発行すると、サーバー・インスタンスはRESUMING
状態を経験します。
RUNNING
状態では、WebLogic Serverは完全に機能しており、クライアントにサービスを提供し、クラスタの正規メンバーとして機能できます。
サーバー・インスタンスは、起動コマンドあるいはADMIN
状態またはSTANDBY
状態からの再開コマンドの結果として、RUNNING
状態に遷移します。
RUNNING
状態のサーバー・インスタンスを、中断コマンド、強制中断コマンド、停止コマンド、または強制停止コマンドを使用してSUSPENDING
状態またはFORCE_SUSPENDING
状態に遷移できます。
この遷移状態中に、WebLogic ServerはADMIN
状態への移動に必要な処理を実行します。一部のWebLogic Serverサブシステムおよびサービスを順に中断し、進行中のアプリケーション作業(「処理中の」作業)の事前に定義済みの部分を完了します。
中断コマンドを発行すると、サーバー・インスタンスはSUSPENDING
状態に遷移します。停止コマンドを発行すると、サーバー・インスタンスはSUSPENDING
状態を経験します。
処理中の作業については、「中断および停止時における処理中の作業の処理」を参照してください。
注意: SUSPENDING 状態の間に、ワーク・マネージャが、アプリケーション・スレッドで保留になっている処理中の作業を完了させます。ただし、この状態の間には新しい作業をワーク・マネージャにスケジューリングできません。詳細は、『Oracle WebLogic Serverサーバー環境の構成』のワーク・マネージャに関する項を参照してください。 |
この遷移状態中に、WebLogic ServerはADMIN
状態への移動に必要な処理を実行します。一部のWebLogic Serverサブシステムおよびサービスを順に中断します。FORCE_SUSPENDING
状態では、WebLogic Serverは、処理中の作業を正常に完了しません。進行中のアプリケーション作業は破棄されます。
強制中断コマンドまたは強制停止コマンドを発行すると、サーバー・インスタンスはFORCE_SUSPENDING
状態を経験します。
この遷移状態では、WebLogic Serverは、サブシステムおよびサービスの中断を完了し、アプリケーション・リクエストも管理リクエストも受け付けません。
停止コマンドまたは強制停止コマンドを発行すると、サーバー・インスタンスはSHUTTING_DOWN
状態を経験します。
メモリー不足例外やアプリケーション・スレッドのスタック状態の結果として、あるいは1つまたは複数の重要なサービスが機能しなくなった場合に、実行中のサーバー・インスタンスで障害が発生することがあります。サーバー・インスタンスは自身の状態をモニターし、1つまたは複数の重要なサブシステムが不安定になっていることを検出すると、自身の状態をFAILED
と宣言します。
FAILED
状態になると、サーバー・インスタンスは障害のない状態に戻ろうとします。ADMIN
状態になる前に障害が発生した場合には、サーバー・インスタンスはゼロより小さい終了コードを返して自身を停止します。サーバーの終了コードについては、「WebLogic Serverの終了コードと障害後の再起動」を参照してください。
ADMIN
状態になった後で(ただし、RUNNING
状態になる前)で障害が発生した場合には、サーバー・インスタンスはデフォルトではADMIN
状態に戻ります(管理ポートが有効になっている場合)。
注意: 必要であれば、ADMIN 状態になった後に障害が発生した場合でも、ADMIN 状態に戻らずに停止するように、サーバー・インスタンスを構成できます。 |
サーバー・インスタンスは、どの状態からでもFAILED
状態になることができます。ただし、サーバー・インスタンスがFAILED
状態になってからは、実行状態に直接戻ることはできません。FAILED
状態は致命的なものであり、サーバーはRUNNING
状態に戻る前に、ADMIN
またはSHUTDOWN
状態に入る必要があります。
注意: 理論上、サーバーはFAILED 状態に入った後、たとえば障害が発生した状態を引き起こしていたハングしているスレッドが、ハングしていない状態になった場合などには、再び使用可能になることがあり得ます。
しかし、一度 |
OverlaodProtectionMBean
を使用してSHUTDOWN
などの自動アクションを構成したり、サーバー・インスタンスがFAILED
状態に入ったときにADMIN
状態に移動したりできます。
この項では、各ライフサイクル・コマンド、その発行方法、およびサーバー・インスタンスの状態への影響について説明します。詳細は、次を参照してください。
ライフサイクル・コマンドの発行方法については、以下を参照してください。
『Oracle WebLogic Scripting Tool』のライフサイクル・コマンドおよび「サーバーのライフサイクルの管理」
Oracle WebLogic Server管理コンソール・ヘルプの「サーバーの起動と停止」
ノード・マネージャを使用する環境の主要なライフサイクル・イベントに関連するノード・マネージャ・プロセスについては、『Oracle WebLogic Serverノード・マネージャ管理者ガイド』のWebLogic Server環境でのノード・マネージャの機能を参照してください。
各ライフサイクル状態で発生する処理については、「サーバー・ライフサイクルにおけるサーバーの状態について」を参照してください。
サーバーの状態とサーバーのライフサイクルの間の関係を表す図については、図5-1を参照してください。
起動コマンドを実行すると、サーバー・インスタンスは、SHUTDOWN
状態からRUNNING
状態に遷移します。起動コマンドでは、サーバー・インスタンスの初期状態に応じて、状態が次のように遷移します。
SHUTDOWN > STARTING > STANDBY > ADMIN > RESUMING > RUNNING
ServerMBean.StartupMode
属性を使用して、サーバー・インスタンスの起動時の状態を指定できます。その値は管理コンソールで表示され、構成できます。WLSTを使用しても、java weblogic.Server
起動オプションとして指定しても構成できます。コマンド・ライン、管理コンソール、またはconfig.xml
のいずれにも起動モードの値が指定されない場合、デフォルトではRUNNING状態で起動されます。
詳細は、Oracle WebLogic Server管理コンソール・ヘルプの「起動モードの指定」、および『Oracle WebLogic Serverコマンド・リファレンス』のサーバー属性を構成するためのオプションを参照してください。
コマンドの使い方
『WebLogic Scripting Toolコマンド・リファレンス』のstart
、startServer
とnmStart
およびOracle WebLogic Server管理コンソール・ヘルプの「管理コンソールからの管理対象サーバーの起動」を参照してください。
スタンバイ・モードを有効にする起動コマンドを実行すると、サーバー・インスタンスは、SHUTDOWN
状態からSTANDBY
状態に、次の状態遷移のシーケンスで遷移します。
SHUTDOWN > STARTING > STANDBY
コマンドの使い方
『Oracle WebLogic Serverコマンド・リファレンス』の-Dweblogic.management.startupmode
およびOracle WebLogic Server管理コンソール・ヘルプの「スタンバイ・モードでの管理対象サーバーの起動」を参照してください。
管理モードを有効にする起動コマンドを実行すると、サーバー・インスタンスは、SHUTDOWN
状態からADMIN
状態に、次の状態遷移のシーケンスで遷移します。
SHUTDOWN > STARTING > STANDBY > ADMIN
コマンドの使い方
『Oracle WebLogic Serverコマンド・リファレンス』の-Dweblogic.management.startupmode
およびOracle WebLogic Server管理コンソール・ヘルプの「管理モードでの管理対象サーバーの起動」を参照してください。
再開コマンドを実行すると、サーバー・インスタンスは、STANDBY
状態またはADMIN
状態からRUNNING
状態に、次の状態遷移のシーケンスで遷移します。
STANDBY > ADMIN > RESUMING > RUNNING
コマンドの使い方
『WebLogic Scripting Toolコマンド・リファレンス』のresume
およびOracle WebLogic Server管理コンソール・ヘルプの「サーバーの再開」を参照してください。
正常な中断コマンドを実行すると、サーバー・インスタンスは、RUNNING
状態からADMIN
状態に、次の状態遷移のシーケンスで遷移します。このとき、進行中の作業は正常に処理されます。
RUNNING > SUSPENDING > ADMIN
コマンドの使い方
『WebLogic Scripting Toolコマンド・リファレンス』のsuspend
およびOracle WebLogic Server管理コンソール・ヘルプの「サーバーの一時停止」を参照してください。
強制中断コマンドを実行すると、サーバー・インスタンスは、RUNNING
状態からADMIN
状態に、次の状態遷移のシーケンスで遷移します。このとき、進行中の作業は正常には処理されません。
RUNNING > FORCE_SUSPENDING > ADMIN
コマンドの使い方
Oracle WebLogic Server管理コンソール・ヘルプの「サーバーの停止」を参照してください。
正常な停止コマンドを実行すると、サーバー・インスタンスは、RUNNING
状態からSHUTDOWN
状態に、次の状態遷移のシーケンスで遷移します。このとき、進行中の作業は正常に処理されます。
RUNNING > SUSPENDING > ADMIN > SHUTTING_DOWN > SHUTDOWN
コマンドの使い方
『WebLogic Scripting Toolコマンド・リファレンス』のshutdown
およびOracle WebLogic Server管理コンソール・ヘルプの「サーバー・インスタンスの停止」を参照してください。
ServerMBean
には、正常な停止プロセスの長さを制御する2つの属性があります。これらの値については、「SERVER_NAME」
>「制御」>「起動と停止」ページで確認および構成できます。
「停止時にセッションを無視」 - このオプションを有効にすると、WebLogic ServerはすべてのHTTPセッションをただちに中止し、完了やタイムアウトを待つことはありません。デフォルトのタイムアウトは1時間なので、破棄されたセッションのタイムアウトを待つと、正常な停止のプロセスが非常に長くなります。
「正常な停止のタイムアウト」 - サーバー・インスタンスが正常な停止を完了するタイムリミットを指定します。タイムアウト値を指定し、サーバー・インスタンスがその期間内に正常な停止を完了しない場合、WebLogic Serverはそのサーバー・インスタンスで強制停止を実行します。
Oracle WebLogic Server管理コンソール・ヘルプの「正常な停止の制御」および「クラスタのサーバーの停止」を参照してください。
正常な停止と強制停止の両方で、サブシステムはアプリケーションを適切にアンデプロイします。この処理の結果として、サーブレットのdestroy()
またはejbRemove()
などのアプリケーション・コードが停止時に呼び出されることがあります。停止シーケンスにおいては、JMS、JDBC、およびトランザクションはアプリケーションが停止した後で停止します。これにより、アプリケーション・コードからJMS、JDBC、およびトランザクションの各サービスにアクセスすることが可能になります。
強制停止コマンドを実行すると、サーバー・インスタンスは、どの状態からでもSHUTDOWN
状態に遷移します。このとき、進行中の作業は正常には処理されません。強制停止コマンドがRUNNING
状態のサーバー・インスタンスに対して実行されると、状態が次のように遷移します。
RUNNING > FORCE_SUSPENDING > ADMIN > STANDBY > SHUTDOWN
コマンドの使い方
『WebLogic Scripting Toolコマンド・リファレンス』のshutdown
およびOracle WebLogic Server管理コンソール・ヘルプの「サーバー・インスタンスの停止」を参照してください。
強制停止は、即座に実行されます。WebLogic Serverのサブシステムが、現在進行中のすべてのアプリケーション処理を停止します。強制停止は、どの状態のサーバー・インスタンスでも実行できます。
致命的な例外によって強制停止が失敗した場合は、ServerMBean
のServerLifecycleTimeoutVal
属性に指定した秒数後にサーバーが終了します。
注意: クラスタ内のサーバー・インスタンスを強制停止しても、その状態が別のサーバー・インスタンスにレプリケートされていれば、クラスタリングされたサービスがクラスタ内の別のサーバー・インスタンスにフェイルオーバーされます。ただし、以下の例外があります。
|
強制停止時に行われるアンデプロイメント・プロセス、および関連するプログラミング上の考慮事項については、「停止操作とアプリケーションのアンデプロイメント」を参照してください。
次の項では、SUSPENDING
処理およびSHUTTING_DOWN
処理で各サブシステムがどのように進行中の作業を処理するのかを説明します。
Remote Method Invocation (RMI)サブシステムは、3段階で中断します。このプロセスの各段階は、次の段階が始まる前に完了します。
非トランザクション・リモート・リクエストが、非トランザクションRMIサービスによって拒否されます。
クライアントが開始したトランザクション・サービスが、保留中のクライアント・トランザクションが完了するのを待ちます。
リモートRMIサービスが、トランザクションのあるなしに関係なくすべてのリモート・リクエストを拒否します。
以上の段階を経た後は、リモート・クライアント・リクエストは許可されません。管理者権限のあるリクエストと内部システム呼出しは受け付けられます。
クラスタ化サーバー・インスタンスが一時停止を準備するように指示された場合、RMIシステムはすべてのインメモリー・レプリケーション呼出しを拒絶し、他のクラスタ・メンバーがレプリケート・セッションのための新しいホストを選択できるようにします。
一時停止を準備するように指示された後のWebコンテナ・サブシステムは、新しいセッション・リクエストを拒否します。既存のセッションは、その永続性手法に従って処理されます。
永続性なし - 永続性のない保留中のセッションは完了できます。
クラスタでのインメモリー・レプリケーション - セカンダリ・セッションのあるセッションはただちに中断されます。プライマリ・セッションにセカンダリ・セッションがない場合、Webコンテナはセカンダリ・セッションが作成されるか、またはセッションがタイムアウトになるまで待機します。
JDBC永続性とファイル永続性 - Webコンテナは、データベースまたはファイル・ストアにレプリケートされたセッションをただちに中断します。
保留セッションの完了は省略可能です。すべてのセッションをただちに中止するには、管理コンソールのSERVER_NAME
>制御>「起動と停止」ページの「停止時にセッションを無視」オプションを使用するか、WLSTのshutdown
コマンドで-ignoreSessions
オプションを使用します。
クラスタでプライマリ・セッションが中止されると、正常に停止されるサーバー上のプライマリ・セッションだけでなく、それに対応する、別のクラスタ化インスタンス上のレプリケートされたセッションも破棄されます。
タイマー・サービスは、アプリケーション実行キューで動作しているすべてのトリガーを取り消します。アプリケーション実行キューには、デフォルト・キューとExecuteQueueMBean
を通じて構成されたキューがあります。
アプリケーション・サービスは、中断の前にアプリケーション・キューの保留作業を完了します。アプリケーション実行キューには、デフォルト・キューとExecuteQueueMBean
を通じて構成されたキューがあります。
Java Messaging Service (JMS)は、それ自身に中断のマークを付けます。これにより、新しいリクエストは拒否されます。JMSシステムは、以下の手順で正常に中断します。
停止するサーバー・インスタンスにJMSサーバーが含まれている場合:
停止するサーバー・インスタンスにJMS接続ファクトリが含まれている場合:
クライアント接続がクローズされます。
通常、JMSサブシステムの正常な中断の各ステップはすばやく(1秒未満で)実行されます。ただし、リクエストが通常よりも速いディスクI/Oを必要とする場合(たとえば、100MBのメッセージの永続「送信」のリクエストなど)は、クライアント・リクエストを完了するのにこれより長い時間がかかることもあります。
JMSサーバーへの接続の数、JMS接続ファクトリのコンシューマの数、および関連する実行時情報は、JMSRuntimeMbean
、JMSConnectionRuntimeMBean
、JMSConsumerRuntimeMBean
などのJMS実行時MBeanを使用してモニターできます。
JDBCサービスは、接続プール中のアイドル状態の接続をクローズします。
注意: 接続がまだ使用されている場合は、JDBCサービスの停止が失敗し、正常な停止は完了しません。アプリケーションがまだ接続を使用している場合、サーバー・インスタンスを停止するには強制停止コマンドを使用します。詳細については、「強制停止」を参照してください。 |