| Oracle® Fusion Middleware高可用性ガイド 12c (12.1.2) E47984-02 |
|
 前 |
 次 |
この章では、Oracle Application Development Framework (ADF)に固有の手順について説明します。
|
注意: この章の内容は、このガイドの他の章とは異なり、管理者よりもADFの開発者の方を対象としています。 |
内容は次のとおりです。
|
関連項目: ADFの詳細は、次のものを参照してください。
|
Oracle ADFテクノロジ・スタック上に構築されるFusion Webアプリケーションは、Java EEアプリケーション(およびJ2EEアプリケーション)です。この項の内容は次のとおりです。
バインディング・コンテナやマネージドBeanなどのADFオブジェクトは、実行時にインスタンス化されます。これらの各オブジェクトには、そのスコープ属性によって設定される存続期間が定義されています。
詳細は、『Oracle Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のオブジェクト・スコープのライフサイクルに関する項を参照してください。
Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内で他に利用可能なメンバーがリクエストを処理できます。この項では、アプリケーションのフェイルオーバー要件およびフェイルオーバーの発生時に予想される動作について説明します。
セッションのフェイルオーバー要件
Fusion Webアプリケーションでシームレスなフェイルオーバーを実現するために、アプリケーションは次の条件を満たす必要があります。
アプリケーションがクラスタ内にあり、アプリケーション・クラスタの少なくとも1つのメンバーが、リクエストへの対応に利用できます。
ステートフル・アプリケーションに対し、第8.2項「高可用性のためのOracle ADFの構成」の説明に従って、状態のレプリケーションが正しく構成されています。
Oracle HTTP Serverを使用している場合は、WebLogicClusterディレクティブを使用して、すべての使用可能なアプリケーション・インスタンス間でバランスが取られるようにサーバーが構成されています。
ハードウェア・ロード・バランサを使用する場合は、ロード・バランサが:
利用可能なインスタンスすべてに対してトラフィックをルーティングしています
利用できないインスタンスをマークするように、ヘルス・モニターで正しく構成されています
セッションの状態の永続性をサポートするように構成されています
アプリケーションのフェイルオーバーで予想される動作
環境が正しく構成されている場合には、クラスタ内のアプリケーション・インスタンスがいつ使用できなくなったか、アプリケーション・ユーザーは気が付きません。たとえば、アプリケーション・フェイルオーバーにおけるイベントの順序は次のようになります。
ユーザーがリクエストを行い、ハードウェア・ロード・バランサによって、アプリケーションのインスタンスAにルーティングされます。
ノード、プロセスまたはネットワークに障害が発生したため、アプリケーションのインスタンスAが使用できなくなります。
ハードウェア・ロード・バランサによって、インスタンスAが使用不可とマークされます。
ユーザーが後続のリクエストを行います。このリクエストがインスタンスBにルーティングされます。
インスタンスBがインスタンスAのレプリケーション・パートナとして構成され、ユーザーのセッションの状態が格納されます。
インスタンスBのセッションの状態を使用してアプリケーションが再開し、ユーザーは中断されることなく、引き続き操作します。
Oracle JRF非同期Webサービス(固定サービスの動作)
Oracle JRF非同期Webサービスを使用している場合は、非同期Webサービスがサービスに固定されるため、フェイルオーバーは実行されません。WS-RMなどの信頼性の高いプロトコルを使用している場合は、障害の発生後に、より上位レベルのプロトコルによって新しいサーバーへの再接続が実行されます。
Oracle JRF非同期Webサービスの詳細は、『ドメイン・テンプレート・リファレンス』を参照してください。
冗長なデータベースやバックエンドとしてのOracle Real Application Clusters (Oracle RAC)など、可用性の高いデータベース・システムにアクセスするようにADFアプリケーション・モジュールを構成するときは、データ・ソースのコンテナが定義されている必要があります。このシナリオでは、GridLinkデータ・ソースまたはマルチ・データ・ソースを使用する必要があります。ただし、アプリケーション・モジュールの構成の観点からは、マルチ・データ・ソースまたはGridLinkデータ・ソースの命名規則は、非マルチ・データ・ソースまたはGridLinkデータ・ソースのネーミング規則と同じになります。この命名規則によって、正しいデータ・ソースが実行時に使用されるようになります。
高可用性アプリケーションに対してGridLinkデータ・ソースを構成する場合は、第4.4項「Oracle RACでのアクティブなGridLinkデータ・ソースの構成」を参照してください。マルチ・データ・ソースの詳細は、第4.5.1項「Oracle RACでのマルチ・データ・ソースの構成」を参照してください。
mdsDSデータ・ソースのURLの変更
顧客が用意したADFアプリケーションでGridLinkデータ・ソースまたはマルチ・データ・ソースを使用する場合は、管理サーバーの起動後に、WebLogic Server管理コンソールでmdsDSデータ・ソースのURLを変更する必要があります。
mdsDSデータ・ソースのURLを変更するには、次の手順を実行します。
WebLogic Server管理コンソールにログインします。「サービス」→「データ・ソース」を選択します。
「mdsDS」→「接続プール」を選択します。
JDBCのURLを指定するように次の形式で変更します。
jdbc:oracle:thin:@hostname:port/service-name
たとえば、次のようなJDBCのURLを想定します。
jdbc:oracle:thin:@(DESCRIPTION=(ENABLE=BROKEN)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=slc00erterw-r.us.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=srv2_koala.us.example.com)))
このURLを次のように置き換えます。
jdbc:oracle:thin:@slc00erterw-r.us.example.com:1521/srv2_koala.us.example.com
変更を保存して、管理サーバーを含むすべてのサーバーを再起動します。
クラスタ環境内のWebアプリケーションに対して自動的なレプリケーションとフェイルオーバーをサポートするために、Oracle WebLogic Serverは、クラスタ間でHTTPセッションの状態をレプリケートするメカニズムをサポートしています。Fusion Webアプリケーションの状態をクラスタ内のどのサーバーからでもリストアできるようにOracle ADFを構成できます。
この項の内容は次のとおりです。
アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。これによって、エンド・ユーザー・タスクに関連した作業論理ユニットに関連する、更新可能なデータ・モデルやトップレベルのプロシージャおよびファンクション(サービス・メソッド)を定義します。アプリケーション・モジュールは、そのトランザクション状態を非アクティブ化する、またはスナップショットとしてデータベースに格納することをサポートしています。また、これらの保存済スナップショットのいずれかからトランザクション状態をアクティブ化する逆の操作もサポートしています。
アプリケーション・モジュールの状態管理の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のFusion Webアプリケーションの状態管理の概要に関する項を参照してください。
ADFビジネス・コンポーネントのフェイルオーバーのサポートを有効にするには、jbo.dofailoverパラメータをtrueに設定し、アプリケーション・モジュールの状態が解放時に保存されるようにします。これによって、Oracle ADFは、前のチェックインで保存されたスナップショットからアプリケーション・モジュールの状態をリストアできるようになります。一方、フェイルオーバー機能がデフォルトにより無効のままになっている場合は、アプリケーションが後続のユーザー・セッションで再利用されたときと、アプリケーション・モジュール・プールが未使用のアプリケーション・モジュールを見つけられないときにのみ、アプリケーション・モジュールの状態が保存されます。
アプリケーション・モジュールの構成でこのパラメータを設定するには、「ビジネス・コンポーネント構成の編集」ダイアログの「プーリングおよびスケーラビリティ」タブを使用します。
高可用性のためのアプリケーション・モジュールを構成する手順は次のとおりです。
JDeveloperを起動してアプリケーションを開きます。
アプリケーション・ナビゲータで、データ・モデルを含むプロジェクトを展開し、アプリケーション・モジュールを探します。
アプリケーション・モジュールを右クリックし、「構成」を選択します。
「編集」をクリックします。
「プーリングおよびスケーラビリティ」タブをクリックします。
「管理された解放時にトランザクションの状態をフェイルオーバー」チェック・ボックスを選択します。
「OK」をクリックして「ビジネス・コンポーネント構成の編集」ダイアログを閉じます。
「OK」をクリックして「構成の管理」ダイアログを閉じます。
HTTPセッションの状態のレプリケートをサポートできるようにするには、Oracle WebLogic Server weblogic.xmlファイルのpersistent-store-type要素に値を割り当てる必要があります。replicated_if_clusteredの値により、有効な永続ストアのタイプがレプリケートされ、このサーバーの属するサーバーのクラスタに対して設定された値に従って、クラスタ環境のセッションが格納されるようになります。
|
注意: Oracle WebCenterポータルSuiteなどのOracle ADFアプリケーションは事前に構成されており、追加構成は不要です。 |
高可用性を実現するためにweblogic.xmlファイルを構成する手順は次のとおりです。
JDeveloperを起動してアプリケーションを開きます。
アプリケーション・ナビゲータで、Webアプリケーションを含むプロジェクトを展開し、WEB-INFフォルダを展開します。
weblogic.xmlファイルをダブルクリックし、「ソース」タブをクリックしてファイルを編集します。
ファイル内で、persistent-store-typeの定義をsession-descriptor要素に追加します。
<weblogic-web-app>
<session-descriptor>
<persistent-store-type>
replicated_if_clustered
</persistent-store-type>
</session-descriptor>
</weblogic-web-app>
クラスタ環境で実行するアプリケーションを設計している場合は、ADFスコープ(ビュー・スコープおよびページ・フロー・スコープ)に格納されているマネージドBeanの変更をOracle ADFが認識していることを確認する必要があります。
ビュー・スコープまたはページ・フロー・スコープのいずれかで、マネージドBean内の値が変更された場合には、アプリケーションがOracle ADFに通知して、Beanの新しい値がレプリケートできるようにする必要があります。
ADF ControllerがADFメモリー・スコープに対する変更を追跡し、サーバー・クラスタ内のページ・フロー・スコープおよびビュー・スコープをレプリケートできるようにするには、アプリケーションのadf-config.xmlファイル内のADF Controllerパラメータ<adf-scope-ha-support>をtrueに設定する必要があります。たとえば、アプリケーションにtrueを設定した場合、そのアプリケーションがリクエスト中にページ・フロー・スコープでBeanの追加または削除を行うと、変更がクラスタ内で自動的にレプリケートされます。
adf-config.xmlは、すべてのADFコンポーネントの中核となる構成ファイルです。このファイルには、ADF ControllerなどのADFコンポーネントの実行時の動作を構成するためのセクションが含まれています。
|
注意: アプリケーションでMDSを使用しており、フェイルオーバーをサポートするOracle Databaseを使用する場合は、フェイルオーバー時におけるMDSの再試行を有効化しておくことをお薦めします。これを行うには、次の
<persistence-config>
<metadata-namespaces>...
<metadata-store-usages>...
<external-change-detection enabled="false" />
<read-only-mode enabled="true"/>
<retry-connection enabled="true"/>
</persistence-config>
|
高可用性を実現するためにadf-config.xmlファイルを構成する手順は次のとおりです。
JDeveloperを起動してアプリケーションを開きます。
アプリケーション・ナビゲータで、「アプリケーション・リソース」を展開します。
「ディスクリプタ」を選択し、「ADF META-INF」ノードを選択します。
adf-config.xmlファイルをダブルクリックし、「ソース」タブをクリックしてファイルを編集します。
このファイルに次の行を追加します。
<adf-controller-config xmlns="http://xmlns.example.com/adf/controller/config"> <adf-scope-ha-support>true</adf-scope-ha-support> </adf-controller-config>
adf-config.xmlファイルを使用したADFの構成の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の複雑なタスク・フローの作成に関する章を参照してください。
高可用性環境で実行する場合、org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATIONパラメータをtrueに設定しないでください。このコンテキスト・パラメータをtrueに設定すると、フェイルオーバーの発生後にエラーを引き起こす可能性があります。通常、このパラメータは開発環境のみに使用し、高可用性環境では使用しないため、この制限が操作に影響することはありません。
この項では、Oracle ADFで発生する可能性のある問題のトラブルシューティング手順について説明します。この項では、次の項目について説明します。
Fusion WebアプリケーションをOracle JDeveloperで開発する場合は、この統合開発環境によって、高可用性に関する問題を検出するためのサポートが提供されます。JDeveloperが発する警告は監査フレームワークによって生成され、JDeveloperのソース・エディタに表示するようにトリガーされます。エディタに表示される警告は、高可用性アプリケーションの監査ルールに基づきます。
JDeveloperによりデフォルトで有効になる高可用性監査ルールは次のとおりです。
「ADF Controller構成 - ADFスコープの高可用性が有効になっていません」は、adf-config.xmlファイル内のadf-scope-ha-supportフラグがtrueに設定されていないことを警告します。この監査ルールは、<adf-controller-config>要素がADFアプリケーションレベルの構成ファイル(adf-config.xml)に存在する場合にのみ適用されます。
「ADFページ・フロー - スコープ・マップのBeanが変更されました」は、コードがBeanでsetterメソッドを呼び出す際、続いてControllerContext.markScopeDirty()メソッドを呼び出さなかったことを開発者に警告します。この監査ルールは、adf-config.xmlファイル内のadf-scope-ha-supportフラグがtrueに設定されている場合にのみ適用されます。
「ADFページ・フロー - EL Beanが変更されました」は、BeanをミューテーションするEL式をコードが評価する際、続いてControllerContext.markScopeDirty()メソッドを呼び出さなかったことを開発者に警告します。この監査ルールは、adf-config.xmlファイル内のadf-scope-ha-supportフラグがtrueに設定されている場合にのみ適用されます。
「ADFページ・フロー - マネージドBeanクラスはシリアライズ不可」は、マネージドBeanのviewScope、pageFlowScopeまたはsessionScopeに、シリアライズ不可のクラスが定義されていることを開発者に警告します。この監査ルールは、adf-config.xmlファイル内のadf-scope-ha-supportフラグがtrueに設定されている場合にのみ適用されます。
高可用性監査ルール設定は、JDeveloperの「設定」ダイアログを使用して変更できます。JDeveloperのツールバーで「ツール - 設定」を選択し、「監査 - プロファイル」の下にある「ADF Controller構成」または「ADFページ・フロー」を展開して、目的の監査ルールを選択します。
JDeveloperのツールバーで「ビルド - 監査 project.jpr」を選択して監査をトリガーすることもできます。
ADFのデプロイメントに関する問題に直面した場合は、実施する2つの対応として、JRFランタイムの確認とアプリケーションのデプロイメント・ステータスの確認を行います。
ADFのデプロイメントをトラブルシューティングする最初の手順では、WebLogic Serverドメイン上にJRFランタイムがインストールされているかどうかを確認します。ADFのアプリケーションには、JRFとADFのランタイムが必要です。スタンドアロンのWebLogic Serverドメインまたはアプリケーション開発の製品に含まれているWebLogic ServerだけではADFのアプリケーションを実行できないため、JRF拡張テンプレートを使用して拡張する必要があります。
JRFテンプレートの詳細は、『Oracle Fusion Middlewareドメイン・テンプレート・リファレンス』のOracle JRFおよびADFのテンプレートに関する項を参照してください。
Fusion Webアプリケーションは、管理対象サーバーを最初に起動したときにデプロイされます。すべてのアプリケーションが正常にデプロイされたかどうかは、管理コンソールを使用して確認します。
左側のペインで「デプロイメント」をクリックします。右側のペインに、アプリケーション・デプロイメントおよびそのステータスが表示されます。すべてのサーバーが稼働中と想定すると、すべてのアプリケーションの状態はACTIVEになっている必要があります。
アプリケーションのデプロイメントが失敗した場合には、アプリケーションが正常にデプロイされなかった理由がサーバー・ログに示されることがあります。サーバー・ログは、DOMAIN_HOME/servers/server_name/logsディレクトリに格納されています。一般的な問題には、次のようなものがあります。
データベース・リソースなどの外部リソースを使用できません。エラーを調べて修正し、アプリケーションを再デプロイしてみてください。
適切なアプリケーションまたはライブラリのターゲットが、目的の管理対象サーバーまたはクラスタに正しく設定されていません。
フェイルオーバーのシナリオでは、状態のレプリケーションが最も顕著です。あるサーバーで作業しているユーザーは、フェイルオーバー時に次のことを検出する場合があります。
ウィンドウが閉じたか、または状態がリセットされた可能性がある。
画面のリセットが必要になった可能性がある。
アプリケーションがログオン画面にリダイレクトしている可能性がある。
状態のレプリケーションに関する問題の診断およびトラブルシューティングを行う手順は、次のとおりです。
これがレプリケーションに関する既知の問題でないことを確認します。
予想される動作については、第8.1.2項「Oracle ADFのフェイルオーバーおよび予想される動作」を参照してください。問題の詳細な診断に進む前に、フェイルオーバーの実際の動作が、予想される動作でないことをまず確認してください。
ロード・バランサの設定を確認します。
レプリケーションとフェイルオーバーが正しく機能するようにするには、ロード・バランサの永続性の設定が適切に構成されている必要があります。Oracle WebLogic Serverのハードウェア・ロード・バランサの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。
クラスタのステータスを確認します。
クラスタのコンテキスト内でレプリケーションが発生します。フェイルオーバーが成功するには、クラスタの正常なメンバーが、他に少なくとも1つ使用可能である必要があります。クラスタのステータスは、次の2種類の方法のどちらかで確認できます。
Oracle WebLogic Server管理コンソールを使用してクラスタのステータスを確認します。左側のペインで「サーバー」をクリックします。クラスタ内のすべてのサーバーの状態を確認します。
weblogic.Adminユーティリティを使用してクラスタのステータスを確認します。weblogic.Adminユーティリティは、特定のクラスタ内にある全サーバーの状態を問い合せるときに使用できます。例:
$ java weblogic.Admin -url Adminhost:7001 -username <username> -password <password> CLUSTERSTATE -clustername Spaces_Cluster
次のようなメッセージが返されます。
There are 2 server(s) in cluster: Spaces_Cluster The alive servers and their respective states are listed below: Application Server---RUNNING Managed Server---RUNNING
クラスタ通信を確認します。
クラスタ・メンバーがすべて稼働していても、通信に関する問題が発生して、レプリケーション情報をメンバー間で伝達できなくなる場合があります。クラスタ通信は、次の2種類の方法で構成できます。トラブルシューティングは、クラスタ・タイプによって異なります。
ユニキャスト・クラスタ通信の確認: ユニキャスト・クラスタの場合、管理対象サーバー間で、お互いのホストおよびお互いのデフォルトのリスニング・ポートにアクセスできる必要があります。
個々の管理対象サーバーすべてで、「リスニング・アドレス」が適切に設定されていることを確認します。この設定は、管理対象サーバーごとに「構成」→「一般」を選択して調べることができます。
マルチキャスト・クラスタ通信の確認: マルチキャスト・クラスタの場合、サーバーは同じマルチキャスト・トラフィックをインターセプトできる必要があります。各マシンでWebLogicユーティリティutils.MulticastTestを実行して、マルチキャストが正しく構成されていることを確認します。例:
$ java utils.MulticastTest -H
Oracle WebLogic Serverアプリケーションの構成を確認します。
Oracle WebLogic Serverは、デフォルトではフェイルオーバーするように構成されていません。メモリー内のレプリケーションは、weblogic.xmlファイルに次の適切な設定が含まれている場合にのみ行われます。
<session-descriptor> <persistent-store-type>replicated_if_clustered</persistent-store-type> </session-descriptor>
replicatedのpersistent-store-typeも受け入れられます。この設定は、第8.2.2項「weblogic.xmlの構成」で説明されているように、JDeveloperで行うことができます。
Oracle ADFビジネス・コンポーネントの構成を確認します。
Oracle ADFは、デフォルトではフェイルオーバーするように構成されていません。フェイルオーバーは、ADFビジネス・コンポーネントの構成ファイル(bc4j.xcfg)に次の適切な設定が含まれている場合にのみサポートされます。
<AppModuleConfig ... <AM-Pooling jbo.dofailover="true"/> </AppModuleConfig>
この設定は、第8.2.1項「アプリケーション・モジュールの構成」で説明されているように、JDeveloperの「ビジネス・コンポーネント構成の編集」ダイアログで行います。
Oracle WebLogic Serverの接続プール・パラメータを確認します。
weblogic-application.xmlデプロイメント・ディスクリプタの要素<connection-check-params> pool-paramsにあるパラメータinactive-connection-timeout-secondsに適切な値を設定します。
アプリケーション・モジュール状態の非アクティブ化を有効にしている場合は、接続を強制的にプールに復帰させるようにOracle WebLogic Serverを構成していると障害が発生することがあります。この障害によって、例外Connection has already been closedが生成されます。この例外は、サーバー・ログに保存されます。ユーザー・インタフェースには、この例外は表示されません。
inactive-connection-timeout-secondsは、数分に設定します。多くの場合は、この設定値によって、非アクティブ接続の強制的なタイムアウトと、非アクティブ化障害を回避できます。ご使用の環境に合せて、この設定値を調整してください。
ADF Controllerの構成を確認します。
Oracle ADFは、デフォルトでは、ADFオブジェクトに対する変更をADFメモリー・スコープ内にレプリケートするように構成されていません。ADFオブジェクトのレプリケーションは、ADFアプリケーションレベルの構成ファイル(adf-config.xml)に次の適切な設定が含まれている場合にのみサポートされます。
<adfc:adf-controller-config> <adfc:adf-scope-ha-support>true</adfc:adf-scope-ha-support> </adfc:adf-controller-config>
この設定は、JDeveloperのソース・エディタを使用して行います。第8.2.1項「アプリケーション・モジュールの構成」を参照してください。
デフォルトのロガー・メッセージを確認します。
デフォルトでは、ADFのログには上位レベルのメッセージ(INFOレベル)が表示されます。デフォルトのログ出力では、さらに詳細なログ・メッセージを有効にする必要なしに、シリアライズやレプリケーションに関する問題を報告することがよくあります。
ADF高可用性アプリケーションのログ・メッセージを有効にします。
ADFロガーを、高可用性のランタイム・メッセージを出力するように構成します。デフォルトでは、ADFのログには上位レベルのメッセージ(INFOレベル)が表示されます。Fusion Middleware Controlでロギング・レベルをFINEに設定して、ADF Controllerの高可用性の診断を有効にします。
有効にすると、adf-config.xmlファイルにadfc:adf-scope-ha-supportが設定されていない場合に、ロガーが警告を出力するようになります。
デバッグを有効にします。
サーバー・ログを調べて、管理対象サーバーの起動時に異常なメッセージがないか確認します。この確認は、管理対象サーバーがクラスタの他のメンバーを見つけられない場合に、特に必要です。サーバー・ログは、DOMAIN_HOME/servers/SERVER_NAME/logsディレクトリに格納されています。
詳細な診断を行うには、DebugCluster、DebugClusterAnnouncements、DebugFailOver、DebugReplication、DebugReplicationDetailsの各フラグを有効にします。各フラグは、weblogic.Adminユーティリティを使用して次のように有効にできます。
$ java weblogic.Admin -url Adminhost:7001 -username <username> -password <password> SET -type ServerDebug -property DebugCluster true
コンポーネントの状態のシリアライズ・チェックを有効にします。
サーバーのチェックを有効にして、セッション属性でシリアライズ不能な状態コンテンツが検出されないようにします。このチェックは、デフォルトでは、実行時のオーバーヘッドを軽減するために無効になっています。シリアライズ・チェックは、Javaサーバーのシステム・プロパティorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATIONによってサポートされます。
表8-1は、このプロパティで使用できるオプションを示しています。オプションを区切るには、カンマを使用します。
表8-1 CHECK_STATE_SERIALIZATIONのオプション
| オプション | 説明 |
|---|---|
|
tree |
コンポーネント・ツリー全体がシリアライズ可能であるかどうかをチェックします。これは、最も高速なコンポーネント・チェックです。大部分のテストは、このフラグを有効にして実行してください。 |
|
component |
シリアライズ可能性について各コンポーネントを個別にチェックします。このオプションは、treeと比較するとかなり低速です。これは、通常、treeのテストでエラーが報告された後にのみ有効にします。このオプションは、問題のあるコンポーネントを絞り込みます。 |
|
property |
シリアライズ可能性について各コンポーネント属性を個別にチェックします。これはcomponentよりも低速であり、treeまたはcomponentモードで障害が検出された後に問題のある特定のコンポーネント属性を絞り込みます。 |
|
session |
シリアライズ可能とマークされているJSF Session Mapのすべての属性がシリアライズ可能であることをチェックします。 |
|
application |
シリアライズ可能とマークされているJSF Application Mapのすべての属性がシリアライズ可能であることをチェックします。 |
|
beans |
該当するマップのシリアライズ可能なオブジェクトのシリアライズ可能なコンテンツがリクエスト中に変更された場合に、そのオブジェクトがダーティとマークされたことをチェックします。 |
|
all |
すべてをチェックします。 |
高可用性をテストするには、まず次のシステム・プロパティを使用してアプリケーション・サーバーを起動し、セッションおよびJSFの状態がシリアライズ可能であることを確認します。
-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=session,tree
次のようにbeansオプションを追加して、該当するマップのシリアライズ可能なオブジェクトのシリアライズされたコンテンツがリクエスト中に変更された場合に、そのオブジェクトがダーティとマークされたことをチェックします。
-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=session,tree,beans
JSFの状態がシリアライズ不能であることが検出された場合は、次のシステム・プロパティを使用してアプリケーション・サーバーを再起動し、コンポーネントとプロパティのフラグを有効にしてからテストを再実行します。
-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=all
これらはJavaシステム・プロパティで、アプリケーション・サーバーを起動する際にこれらを指定する必要があります。
