このバージョンでは、問題の自動検出とリカバリー機能に焦点を当てた、 製品のトラブルシューティングとサービス提供のための多くの新規フィーチャーを提供しています。
バージョン 6.1 での新機能 ! バージョン 6.1 レベルで実装された、 新規フィーチャーまたは変更点を示します。 マークが付いていない項目は、 バージョン 6.1 にも適用されるバージョン 6.0 の改善点です。 これらの項目は、バージョン 5.x からバージョン 6.1 にマイグレーションする、すべてのユーザーに役立ちます。 |
非推奨のフィーチャーと除去されたフィーチャー では、 このリリースまたは将来のリリースで差し替えまたは廃止されるフィーチャーについて説明しています。
障害からのリカバリーを管理する機能の改良 | トランザクション・リカバリー処理を行っているアプリケーション・サーバーに新規作業を割り当てないようにするには、
リカバリー・モードでアプリケーション・サーバーを再始動します。
リカバリー・モードでのアプリケーション・サーバーの再始動 を参照してください。 |
診断プロバイダーによる問題判別の容易化および高速化 | バージョン 6.1 での新機能 ! 診断プロバイダーは、
コンポーネントの実行に関する情報を明らかにするため、管理者は、コンポーネントに関連した問題をより簡単に
デバッグできます。問題をより速く検出し、問題を判別し解決するためにより多くの情報を利用できます。
診断プロバイダーでの作業 を参照してください。 |
IBM Support Assistant | IBM Support Assistant (ISA) は、問題解決のための、適切な look-here-first 機能
を提供します。これは、問題判別ツール、および選択した製品用に外部で使用可能なサポート・リソースへアクセス
するための単一ポイントを提供します。これを使用すると、差し迫った問題を探り、解決に導いてくれます。以下の操作が可能です。
IBM サポート・アシスタントの取得 を参照してください。 |
サポート・サイトの新規トラブルシューティング・テクノロジー | |
障害の発生時により多くの診断データが収集される | First Failure Data Capture (FFDC) フィーチャーは、処理の失敗によって生成された情報を保存し、
それによって影響を受けるエンジンに制御を戻します。
取り込まれたデータは、問題の分析用にログ・ファイルに保管されます。FFDC は、主として IBM サービスが使用するためのものです。
First Failure Data Capture ログ・ファイル・パージの構成 を参照してください。 |
クラス・ローダー・ビューアー | クラス・ローダーは、クラス・ファイルを検出し、ロードします。デプロイされたアプリケーションを正常に稼働させるには、アプリケーションおよびそのモジュールに影響するクラス・ローダーは、アプリケーションが必要とするファイルおよびリソースを検索できるよう構成される必要があります。クラス・ローダーでの問題の診断は、複雑で面倒な場合があります。
問題の診断と修正をより迅速に行うには、管理コンソールのクラス・ローダー・ビューアーを使用して、
クラス・ローダーおよび各クラス・ローダーによりロードされるクラスを調べます。 クラス・ローダーのトラブルシューティング を参照してください。 |
トラブルシューティング文書には、「Web search」ページのカスタマイズされた照会フィールドを使用して、 有効な Web ベース・サポート・リソースを検索する機能など、豊富なサポート情報が含まれています。
メッセージ・テキストの改良、新規メッセージ ID | インストール、マイグレーション、および初期構成中に使用される主要製品コンポーネントのメッセージが改良されました。 追加コンポーネントにメッセージが設定されました。 メッセージ ID は将来のリリースで変更されます。 その間、新規メッセージ ID を使用して、 ユーザーが使用する可能性があり、 メッセージ ID に依存しているツールの準備に役立つよう、 アプリケーション・サーバーを構成できます。 メッセージ参照を使用すると、バージョン 5.1.x を バージョン 6.0.x メッセージ ID にマッピングできます。 ログ・ファイルで使用されるメッセージ ID の変更 では、 アプリケーション・サーバーで新規メッセージ ID を 使用するための方法を説明しています。 さらに、 IBM 固有のメッセージ ID を使用するためのログ・ファイルの変換 には、古いメッセージ ID を持った ログ・ファイルに基づいて、新規メッセージ ID を持ったログ・ファイルを作成するコマンドが説明されています。 このコマンドは、新規メッセージ ID へのマイグレーションを容易にするために提供されています。 バージョン 6.1 での新機能 ! さらに作業が行われて、メッセージおよびそれらのコンポーネント・メッセージ ID が IBM ソフトウェア標準に 対応するようになり、問題判別ツールを使用する際により良い結果が得られるようになりました。メッセージ文書が改良されて、 意味があり、分かりやすいものになりました。 |
Common Base Event によるシステム状態の記述 | Common Base Event はシステムで発生する状態を記述するためのデータ構造です。
Common Base Event は、ビジネス・イベント、構成イベント、エラー・イベントなどの表現を含む、さまざまな目的に使用されます。
現在、WebSphere Application Server は Common
Base Event を記録済みメッセージの内部表現として使用します。 Common Base Event は JSR47 を通して記録され、JSR47 ハンドラーから受信および操作することができます。Common Base Event 仕様に従ってプログラムされていないハンドラーは、これらのイベントを CommonBaseEventLogRecords として使用することもできます。 Common Base Event 仕様に従ってプログラムされたハンドラーは、Common Base Event 内のフィールドを利用できます。 |
Common Base Event インフラストラクチャーに対するプログラミング | バージョン 6.1 での新機能 ! ログ作成用、および 開発者がテンプレート (イベント・ファクトリー・テンプレートまたはイベント・テンプレート) の使用を選択するかしないか に関わらず、生成されたイベントが WebSphere ランタイムによって生成されたイベントと整合するようにするために、 開発者は Common Base Event インフラストラクチャーを利用できます。 |
メモリー・リーク問題のトラブルシューティングのための追加サポート | メモリー・リークが検出された場合、自動化されたヒープ・ダンプ生成サポートを使用し、 メモリー・リーク問題の分析に役立てることができます。 WebSphere Application Server は、 WebSphere Runtime Performance Advisor フレームワーク内で稼働する単純なメモリー・リーク検出メカニズム をインプリメントしています。このメカニズムは、テスト環境および実稼働環境でメモリー問題を初期検出するように設計されています。このフレームワークは、問題の原因を分析するように設計されているのではなく、 通知を提供し、分析ツールを使用するために必要な情報の生成に役立てるように設計されています。 このメカニズムは、Java ヒープ内のメモリー・リークのみを検出し、ネイティブ・リークは検出しません。 単純なメモリー・リーク検出の開始 を参照してください。 |
メモリー・リーク検出の機能拡張 | テスト環境においてメモリー・リークを再発生させることは、 しばしば困難な作業となります。テスト環境でメモリー・リークを再発生させることに関する問題を軽減するために、 WebSphere Application Server は、最小のパフォーマンス・オーバーヘッドで実動システムで実行されるように設計された、 軽量メモリー・リーク検出機能を使用します。この機能により、メモリー・リークを早期に通知できるようになるため、 問題が重大になる前に問題を診断し、不測の事態を解決する時間が生まれます。 バージョン 6.1 での新機能 ! メモリー・リーク検出機能は、メモリー・リークの診断およびトラブルシューティングをより強力にサポートする 新規フィーチャーによって改良されました。 Diagnostic Provider Interface を使用すると、 ユーザーは、メモリー・リークの疑いをチェックする自己診断テストを実行できます。この自己診断により、 問題判別ツールは、通知がないか常に WebSphere Application Server をモニターすることなく、 メモリーの状況をチェックできます。さらに、際限のないヒープを伴う検出をサポートするために、 新規のメモリー・リーク検出ロジックが追加されました。この機能によって、Java ヒープが拡大している最中でも、 すべてのプラットフォームでより堅固な早期の通知を行うことができます。 単純なメモリー・リーク検出の開始 を参照してください。 |
JRAS の非推奨化 | JRAS API は推奨されません。代わりに JSR47 ロギング・インフラストラクチャーの使用を推奨します。
この機能およびその他の非推奨項目についての詳細は、非推奨のフィーチャーと除去されたフィーチャー を参照してください。 |
Jakarta Commons Logging のサポートの追加 | Jakarta Commons Logging は、いくつかのロギング・システムに対して、
単純なロギング・インターフェースおよびシン・ラッパーを提供します。WebSphere
Application Server version 6.0.2 は、WebSphere Application Server ロギング機能用のシン・ラッパー
であるロガーを提供することにより、Jakarta Commons Logging をサポートします。ロガーは、
Java Logging (JSR47) と
Common Base Event ロギング・オブジェクトの両方を処理することができます。 Jakarta Commons Logging の WebSphere Application Server サポートにより、Jakarta Commons Logging で定義されるインターフェースが変更されることはありません。 Jakarta Commons Logging を使用するためのアプリケーションの構成 を参照してください。 |
ログにスレッド名を格納可能 | 拡張ログ・フォーマットおよびログ・アナライザー・トレース・フォーマットにスレッド名が追加されました。ログ・アナライザー・トレース・フォーマットは、Showlog ツールが生成するのと同じフォーマットで
トレース情報を保存します。拡張ログ・フォーマットはトレース・ログおよび System.out
ログの出力フォーマットとして使用できます。
現在、このフォーマットにスレッド名が追加されているため、その他のタイプの診断データとの相関が容易になりました。
ログ・アナライザー・フォーマットはトレース・ログの出力フォーマットとして使用できます。
現在、このフォーマットにスレッド名が追加されているため、その他のタイプの診断データとの相関が容易になりました。
トレース出力 を参照してください。 |
JSR47 からの Java ロギング・フレームワークの活用 | J2SE 1.4 では、JSR47 を通して Java ロギング・フレームワークが導入されました。
WebSphere Application Server では、JRAS と JSR47 の両方のロギング API に記録されたメッセージおよびトレースが JSR47 ロギング・インフラストラクチャーに渡されます。これにより、ルート JSR47 ロガーに接続された JSR47 ハンドラーはすべての WebSphere Application Server ログの内容を受信できます。JSR47 および JRAS ロガー・レベルは、管理コンソールのトラブルシューティング・セクションを通して制御できます。
また、WebSphere Application Server はハンドラーをルート・ロガーに接続して、JSR47 フレームワークからログを構築することもできます。
JSR47 ロギング・インフラストラクチャーでは、カスタム・ハンドラーをロギング・インフラストラクチャーに柔軟に接続して、カスタム・ログを使用可能にすることができます。 適切に構成することにより、ハンドラーは WebSphere Application Server の記録済みイベント、およびアプリケーションによってインスタンス化されたロガーに記録されたイベントを受信できます。 管理コンソールを使用した Java ロギングの構成 を参照してください。 |