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