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