WebLogic Server インスタンスが遷移できる一連の状態の変遷のことを、サーバのライフサイクルといいます。WebLogic Server インスタンスは常に、特定の動作状態にあります。起動、停止、中断などのコマンドは、サーバ インスタンスの動作状態に所定の変化をもたらします。以下の節では、WebLogic Server の状態、状態の遷移、およびライフサイクル コマンドについて説明します。
図 5-1 は、サーバのライフサイクル、および状態とライフサイクル コマンドの間の関係を示しています。
各状態と、状態間の関係を理解するには、「サーバ ライフサイクルにおけるサーバの状態について」を参照してください。ライフサイクル コマンドについては、「サーバのライフサイクル コマンドの使用について」を参照してください。
WebLogic Server は、サーバ インスタンスの現在の状態、およびサーバ インスタンスが起動してからこれまでに起こった状態の遷移に関する情報を表示および保存します。この情報は、以下の作業を行う管理者にとって便利です。
サーバ インスタンスとそれがホストするアプリケーションの可用性をモニタする
起動や停止などの日常のタスクを行う
アプリケーション サービスの問題を診断する
サーバ インスタンスで障害やクラッシュが発生したときに、サービスの移行などの修正アクションを計画する
サーバの状態を取得する方法は、次のとおりです。
Administration Console - 以下の複数のページで状態情報が表示されます。
[サーバの概要] ページ ([環境|サーバ]) の [サーバ] テーブルには、現在のドメインの各サーバ インスタンスの現在の状態が表示される。
[SERVER_NAME
|モニタ] ページには、現在実行されているサーバ インスタンスの状態、およびその状態になった日付と時刻が表示される。
[診断|ログ ファイル] には、サーバ インスタンスが最後に起動してからこれまでに起こった状態遷移のタイムスタンプ付きメッセージが格納されている。
プログラム - サーバの weblogic.management.runtime.ServerRuntimeMBean
の getState()
メソッドを使用します。たとえば、時間のかかる正常な停止プロセスの進捗をモニタするには、独立したスレッドで getstate
を発行します。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「ServerRuntimeMBean
」を参照してください。
WebLogic Scripting Tool - 『Oracle Fusion Middleware 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
状態のサーバ インスタンスの機能は、以下のとおりです。
Administration Console が使用できる。
サーバ インスタンスは、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 Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション』の「ワーク マネージャについて」を参照してください。 |
この遷移状態中に、WebLogic Server は ADMIN
状態への移動に必要な処理を実行します。一部の WebLogic Server サブシステムおよびサービスを順に中断します。FORCE_SUSPENDING
状態では、WebLogic Server は、処理中の作業を正常に完了しません。進行中のアプリケーション作業は破棄されます。
強制中断コマンドまたは強制停止コマンドを発行すると、サーバ インスタンスは FORCE_SUSPENDING
状態を経験します。
この遷移状態では、WebLogic Server は、サブシステムおよびサービスの中断を完了し、アプリケーション要求も管理要求も受け付けません。
停止コマンドまたは強制停止コマンドを発行すると、サーバ インスタンスは SHUTTING_DOWN
状態を経験します。
メモリ不足例外やアプリケーション スレッドのスタック状態の結果として、あるいは 1 つまたは複数の重要なサービスが機能しなくなった場合に、実行中のサーバ インスタンスで障害が発生することがあります。サーバ インスタンスは自身の状態をモニタし、1 つまたは複数の重要なサブシステムが不安定になっていることを検出すると、自身の状態を FAILED
と宣言します。
FAILED
状態のサーバ インスタンスは、管理要求にもクライアント要求にも対応できません。
FAILED
状態になると、サーバ インスタンスは障害のない状態に戻ろうとします。ADMIN
状態になる前に障害が発生した場合には、サーバ インスタンスはゼロより小さい終了コードを返して自身を停止します。サーバの終了コードについては、「WebLogic Server の終了コードと障害後の再起動」を参照してください。
ADMIN
状態になった後で (ただし、RUNNING
状態になる前) で障害が発生した場合には、サーバ インスタンスはデフォルトでは ADMIN
状態に戻ります (管理ポートが有効になっている場合)。
注意 : 必要であれば、ADMIN 状態になった後に障害が発生した場合でも、ADMIN 状態に戻らずに停止するように、サーバ インスタンスをコンフィグレーションできます。 |
サーバ インスタンスは、どの状態からでも FAILED
状態になることができます。ただし、サーバ インスタンスが FAILED
状態になってからは、実行状態に直接戻ることはできません。FAILED
状態は致命的なものであり、サーバは RUNNING
状態に戻る前に、ADMIN
または SHUTDOWN
状態に入る必要があります。
注意 : 理論上、サーバは FAILED 状態に入った後、たとえば障害が発生した状態を引き起こしていたハングしているスレッドが、ハングしていない状態になった場合などには、再び使用可能になることがあり得ます。しかし、一度 |
この節では、各ライフサイクル コマンド、その発行方法、およびサーバ インスタンスの状態への影響について説明します。詳細については、以下を参照してください。
ライフサイクル コマンドの発行方法については、以下を参照。
『Oracle Fusion Middleware Oracle WebLogic Scripting Tool ガイド』の「ライフサイクル コマンド」および「サーバのライフサイクルの管理」
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「サーバの起動と停止」
ノード マネージャ使用環境での、主要なライフサイクル イベントに関するノード マネージャの処理については、『Oracle Fusion Middleware Oracle WebLogic Server ノード マネージャ管理者ガイド』の「WebLogic Server 環境でのノード マネージャの機能」を参照。
各ライフサイクル状態で発生する処理については、「サーバ ライフサイクルにおけるサーバの状態について」を参照。
サーバの状態とサーバのライフサイクルの間の関係を表す図については、図 5-1 を参照してください。
起動コマンドを実行すると、サーバ インスタンスは、SHUTDOWN
状態から RUNNING
状態に遷移します。起動コマンドでは、サーバ インスタンスの初期状態に応じて、状態が次のように遷移します。
SHUTDOWN > STARTING > STANDBY > ADMIN > RESUMING > RUNNING
ServerMBean.StartupMode
属性を使用して、サーバ インスタンスの起動時の状態を指定できます。その値は Administration Console で表示され、コンフィグレーションできます。WLST を使用しても、java weblogic.Server
起動オプションとして指定してもコンフィグレーションできます。コマンドライン、Administration Console、または config.xml のいずれにも起動モードの値が指定されない場合、デフォルトでは RUNNING 状態で起動されます。
詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「起動モードの指定」と『Oracle Fusion Middleware Oracle WebLogic Server コマンド リファレンス』の「サーバ属性をコンフィグレーションするためのオプション」を参照してください。
コマンドの使い方
『Oracle Fusion Middleware WebLogic Scripting Tool コマンド リファレンス』の「start
」、「startServer
」、「nmStart
」と、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「Administration Console からの管理対象サーバの起動」を参照してください。
スタンバイ モードを有効にする起動コマンドを実行すると、サーバ インスタンスは、SHUTDOWN
状態から STANDBY
状態に、次の状態遷移のシーケンスで遷移します。
SHUTDOWN > STARTING > STANDBY
コマンドの使い方
『Oracle Fusion Middleware Oracle WebLogic Server コマンド リファレンス』の「-Dweblogic.management.startupmode
」と、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「スタンバイ モードでの管理対象サーバの起動」を参照してください。
管理モードを有効にする起動コマンドを実行すると、サーバ インスタンスは、SHUTDOWN
状態から ADMIN
状態に、次の状態遷移のシーケンスで遷移します。
SHUTDOWN > STARTING > STANDBY > ADMIN
コマンドの使い方
『Oracle Fusion Middleware Oracle WebLogic Server コマンド リファレンス』の「-Dweblogic.management.startupmode
」と、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「管理モードでの管理対象サーバの起動」を参照してください。
再開コマンドを実行すると、サーバ インスタンスは、STANDBY
状態または ADMIN
状態から RUNNING
状態に、次の状態遷移のシーケンスで遷移します。
STANDBY > ADMIN > RESUMING > RUNNING
コマンドの使い方
『Oracle Fusion Middleware WebLogic Scripting Tool コマンド リファレンス』の「resume
」と Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「サーバの再開」を参照してください。
正常な中断コマンドを実行すると、サーバ インスタンスは、RUNNING
状態から ADMIN
状態に、次の状態遷移のシーケンスで遷移します。このとき、進行中の作業は正常に処理されます。
RUNNING > SUSPENDING > ADMIN
コマンドの使い方
『Oracle Fusion Middleware WebLogic Scripting Tool コマンド リファレンス』の「suspend
」と Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「サーバの中断」を参照してください。
強制中断コマンドを実行すると、サーバ インスタンスは、RUNNING
状態から ADMIN
状態に、次の状態遷移のシーケンスで遷移します。このとき、進行中の作業は正常には処理されません。
RUNNING > FORCE_SUSPENDING > ADMIN
コマンドの使い方
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「サーバの中断」を参照してください。
正常な停止コマンドを実行すると、サーバ インスタンスは、RUNNING
状態から SHUTDOWN
状態に、次の状態遷移のシーケンスで遷移します。このとき、進行中の作業は正常に処理されます。
RUNNING > SUSPENDING > ADMIN > SHUTTING_DOWN > SHUTDOWN
コマンドの使い方
『Oracle Fusion Middleware WebLogic Scripting Tool コマンド リファレンス』の「shutdown
」と Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「サーバ インスタンスの停止」を参照してください。
ServerMBean
には、正常な停止プロセスの長さを制御する 2 つの属性があります。これらの値については、[SERVER_NAME
|制御|起動と停止] ページで確認およびコンフィグレーションできます。
[停止時にセッションを無視] - このオプションを有効にすると、WebLogic Server はすべての HTTP セッションを直ちに中止し、完了やタイムアウトを待つことはありません。デフォルトのタイムアウトは 1 時間なので、破棄されたセッションのタイムアウトを待つと、正常な停止のプロセスが非常に長くなります。
[正常な停止のタイムアウト] - サーバ インスタンスが正常な停止を完了するタイムリミットを指定します。タイムアウト値を指定し、サーバ インスタンスがその期間内に正常な停止を完了しない場合、WebLogic Server はそのサーバ インスタンスで強制停止を実行します。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「正常な停止の制御」と「クラスタ内のサーバの停止」を参照してください。
正常な停止と強制停止の両方で、サブシステムはアプリケーションを適切にアンデプロイします。この処理の結果として、サーブレットの destroy()
または ejbRemove()
などのアプリケーション コードが停止時に呼び出されることがあります。停止シーケンスにおいては、JMS、JDBC、およびトランザクションはアプリケーションが停止した後で停止します。これにより、アプリケーション コードから JMS、JDBC、およびトランザクションの各サービスにアクセスすることが可能になります。
強制停止コマンドを実行すると、サーバ インスタンスは、どの状態からでも SHUTDOWN
状態に遷移します。このとき、進行中の作業は正常には処理されません。強制停止コマンドが RUNNING
状態のサーバ インスタンスに対して実行されると、状態が次のように遷移します。
RUNNING > FORCE_SUSPENDING > ADMIN > STANDBY > SHUTDOWN
コマンドの使い方
『Oracle Fusion Middleware WebLogic Scripting Tool コマンド リファレンス』の「shutdown
」と Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「サーバ インスタンスの停止」を参照してください。
強制停止は、即座に実行されます。WebLogic Server のサブシステムが、現在進行中のすべてのアプリケーション処理を停止します。強制停止は、どの状態のサーバ インスタンスでも実行できます。
致命的な例外によって強制停止が失敗した場合は、ServerMBean
の ServerLifecycleTimeoutVal
属性に指定した秒数後にサーバが終了します。
注意 : クラスタ内のサーバ インスタンスを強制停止しても、そのステートが別のサーバ インスタンスにレプリケートされていれば、クラスタ化されたサービスがクラスタ内の別のサーバ インスタンスにフェイルオーバされます。ただし、以下の例外があります。
|
強制停止時に行われるアンデプロイメント プロセス、および関連するプログラミング上の考慮事項については、「停止操作とアプリケーションのアンデプロイメント」を参照してください。
以下の節では、SUSPENDING
処理および SHUTTING_DOWN
処理で各サブシステムがどのように進行中の作業を処理するのかを説明します。
Remote Method Invocation (RMI) サブシステムは、3 段階で中断します。このプロセスの各段階は、次の段階が始まる前に完了します。
非トランザクション リモート要求が、非トランザクション RMI サービスによって拒否されます。
クライアントが開始したトランザクション サービスが、保留中のクライアント トランザクションが完了するのを待ちます。
リモート RMI サービスが、トランザクションのあるなしに関係なくすべてのリモート要求を拒否します。
以上の段階を経た後は、リモート クライアント要求は許可されません。管理者特権のある要求と内部システム呼び出しは受け付けられます。
クラスタ化されたサーバ インスタンスが中断を準備するように指示された場合、RMI システムはすべてのインメモリ レプリケーション呼び出しを拒絶し、他のクラスタ メンバーがレプリケート セッションのための新しいホストを選択できるようにします。
中断を準備するように指示された後の Web コンテナ サブシステムは、新しいセッション要求を拒否します。既存のセッションは、その永続性手法に従って処理されます。
永続性なし - 永続性のない保留中のセッションは完了できます。
クラスタでのインメモリ レプリケーション - セカンダリ セッションのあるセッションは直ちに中断されます。プライマリ セッションにセカンダリ セッションがない場合、Web コンテナはセカンダリ セッションが作成されるか、またはセッションがタイムアウトになるまで待機します。
JDBC 永続性とファイル永続性 - Web コンテナは、データベースまたはファイル ストアにレプリケートされたセッションを直ちに中断します。
保留セッションの完了は省略可能です。すべてのセッションを直ちに中止するには、Administration Console の [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 サービスの停止が失敗し、正常な停止は完了しません。アプリケーションがまだ接続を使用している場合、サーバ インスタンスを停止するには強制停止コマンドを使用します。詳細については、「強制停止」を参照してください。 |