WS-Notification のトラブルシューティングのヒント

Web サービスのメッセージングの WS-Notification 行うパブリッシュおよびサブスクライブに関するトラブルシューティングのヒント。

[z/OS]WS-Notification の問題を識別して解決するには、コンポーネント・トレース (CTRACE) の設定で説明されているように、WebSphere Application Server トレースおよびロギングの機能を使用します。

WS-Notification のトレースを使用可能にするには、アプリケーション・サーバーのトレース・ストリングを SIBWsn=all=enabled:com.ibm.ws.sib.webservices.*=all=enabled に設定します。 WS-Notification に関連すると思われる問題が生じた場合には、WebSphere Application Server 管理コンソールおよびアプリケーション・サーバーの SystemOut.log ファイルで、エラー・メッセージを調べることができます。アプリケーション・サーバーのデバッグ・トレースを使用可能にして、例外のダンプの詳細を入手することもできます。

注: このトピックでは、 1 つ以上のアプリケーション・サーバー・ログ・ファイルを参照します。推奨される代替案として、分散システムや IBM® i システムの SystemOut.logSystemErr.logtrace.logactivity.log ファイルではなく、High Performance Extensible Logging (HPEL) ログおよびトレース・インフラストラクチャーを使用するようにサーバーを構成できます。また HPEL は、ネイティブ z/OS ロギング機能と連携させて使用することができます。HPEL を使用する場合、LogViewer コマンド・ライン・ツールを サーバー・プロファイルの bin ディレクトリーから使用して、すべてのログ・ファイルにアクセスし、 情報をトレースできます。HPEL の使用について詳しくは、HPEL を使用してのアプリケーションの トラブルシューティングに関する情報を参照してください。

WS-Notification を使用している際に適用する主な既知の制約事項のリストは、WS-Notification: 既知の制約事項に提供されています。

WebSphere Application Server システム・メッセージは、アプリケーション・サーバー・コンポーネントやアプリケーションなど、さまざまなソースからログに記録されます。 アプリケーション・サーバー・コンポーネントによって記録され、IBM 製品に関連したメッセージは、 メッセージを発行したコンポーネントまたはアプリケーションを示す固有のメッセージ ID で始まります。WS-Notification コンポーネントのプレフィックスは、CWSJN です。

トピック『トラブルシューター・リファレンス: メッセージ』には、メッセージ接頭語を索引にして、すべての WebSphere Application Server メッセージに関する情報が記載されています。それぞれのメッセージごとに問題の説明、および問題を解決するために取ることのできるアクションの詳細が記載されています。

以下に、一般的に起こる問題のトラブルシューティングに役立つ一連のヒントを示します。

ブローカー経由の通知のロー・コンシューマーである JAX-WS アプリケーションは、通知ブローカー SOAP アクションを認識しなければならない

JAX-WS はアクション・ベースのディスパッチをサポートし、JAX-WS ロー・コンシューマー・アプリケーションは、http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify アクション URI を受け入れる必要があります。これは以下のいずれかの方法で可能にすることができます。
  • ロー・コンシューマー・アプリケーション WSDL ファイルで、SOAP バインディング情報を変更して、以下の通知アクション URI を含めます。
    <wsdl:operation name="oneWayRawSubscriptionNotify">
        <soap:operation soapAction="http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify" />
        <wsdl:input name="oneWayRawSubscriptionNotifyRequest">
            <soap:body use="literal" />
        </wsdl:input>
    </wsdl:operation>
  • ロー・コンシューマー・アプリケーション WSDL ファイルで、ポート・タイプ情報を変更して、以下の通知アクション URI を含めます。
    <wsdl:operation name="oneWayRawSubscriptionNotify">
        <wsdl:input message="impl:oneWayRawSubscriptionNotifyRequest"
                    name="oneWayRawSubscriptionNotifyRequest"
                    wsam:Action="http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify">
        </wsdl:input>
    </wsdl:operation>
  • JAX-WS アノテーションを使用して、アクション URI http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify をアプリケーション・コードに指定します。 詳しくは、JAX-WS のアノテーションのトピックにある、WebMethod アノテーションの action プロパティーを参照してください。

PublisherRegistrationManager.wsdl ファイルは、JAX-WS バインディング・ファイルを組み込まない限り、wsimport により正しく構文解析されない

WS-Notification アプリケーションの WSDL ファイルを圧縮ファイルに公開する場合、wsimport コマンドを PublisherRegistrationManager.wsdl ファイルに対して実行すると、以下の障害メッセージが表示されます。
[ERROR] the following naming conflicts occurred: 
com.ibm.websphere.wsn.publisher_registration_manager.ResourceNotDestroyedFault
line 2 of file:/path_to_wsdl/PublisherRegistrationManager.wsdl

この障害は、パブリッシャー登録マネージャーの WSDL が、WS-Notification および WS-ResourceLifetime の両方の仕様を使用するために発生します。そのどちらも、同じメッセージ名を共有する ResourceNotDestroyedFault エレメントを参照します。 以下に示すのは、パブリッシャー登録マネージャー WSDL ファイルの、関連する部分です。

  <wsdl:operation name="DestroyRegistration">
    <wsdl:input name="DestroyRegistrationRequest" message="wsn-brw:DestroyRegistrationRequest" 
      wsam:Action="http://docs.oasis-open.org/wsn/brw-2/PublisherRegistrationManager/DestroyRegistrationRequest" 
      wsaw:Action="http://docs.oasis-open.org/wsn/brw-2/PublisherRegistrationManager/DestroyRegistrationRequest"/>
    <wsdl:output name="DestroyRegistrationResponse" message="wsn-brw:DestroyRegistrationResponse" 
      wsam:Action="http://docs.oasis-open.org/wsn/brw-2/PublisherRegistrationManager/DestroyRegistrationResponse" 
      wsaw:Action="http://docs.oasis-open.org/wsn/brw-2/PublisherRegistrationManager/DestroyRegistrationResponse"/>
    <wsdl:fault name="ResourceUnknownFault" message="wsrf-rw:ResourceUnknownFault" 
      wsam:Action="http://docs.oasis-open.org/wsrf/fault" 
      wsaw:Action="http://docs.oasis-open.org/wsrf/fault"/>
    <wsdl:fault name="ResourceNotDestroyedFault" message="wsn-brw:ResourceNotDestroyedFault" 
      wsam:Action="http://docs.oasis-open.org/wsn/fault" wsaw:Action="http://docs.oasis-open.org/wsn/fault"/>
  </wsdl:operation>

<!-- Some parts have been omitted -->

<!-- An extract from WS-ResourceLifetime -->
  <wsdl:operation name="Destroy">
    <wsdl:input name="DestroyRequest" message="wsrf-rlw:DestroyRequest" 
      wsam:Action="http://docs.oasis-open.org/wsrf/rlw-2/ImmediateResourceTermination/DestroyRequest" 
      wsaw:Action="http://docs.oasis-open.org/wsrf/rlw-2/ImmediateResourceTermination/DestroyRequest"/>
    <wsdl:output name="DestroyResponse" message="wsrf-rlw:DestroyResponse" 
      wsam:Action="http://docs.oasis-open.org/wsrf/rlw-2/ImmediateResourceTermination/DestroyResponse" 
      wsaw:Action="http://docs.oasis-open.org/wsrf/rlw-2/ImmediateResourceTermination/DestroyResponse"/>
    <wsdl:fault name="ResourceNotDestroyedFault" message="wsrf-rlw:ResourceNotDestroyedFault" 
      wsam:Action="http://docs.oasis-open.org/wsrf/fault" 
      wsaw:Action="http://docs.oasis-open.org/wsrf/fault"/>
    <wsdl:fault name="ResourceUnknownFault" message="wsrf-rw:ResourceUnknownFault" 
      wsam:Action="http://docs.oasis-open.org/wsrf/fault" 
      wsaw:Action="http://docs.oasis-open.org/wsrf/fault"/>
    <wsdl:fault name="ResourceUnavailableFault" message="wsrf-rw:ResourceUnavailableFault" 
      wsam:Action="http://docs.oasis-open.org/wsrf/fault" 
      wsaw:Action="http://docs.oasis-open.org/wsrf/fault"/>
  </wsdl:operation>

この命名競合を解決するために、JAX-WS バインディング・ファイル ibm-wsn-jaxws.xml を、引数として wsimport コマンドに組み込む必要があります。 このバインディング・ファイルにより、競合する要素は別のクラス名にマップされます。

ibm-wsn-jaxws.xml ファイルは、app_server_root/util ディレクトリーの中にあります。例えば、c:¥was¥util¥ibm-wsn-jaxws.xml です。 このバインディング・ファイルが参照する WSDL ファイルは、このバインディング・ファイルと同じディレクトリー内にあることを前提としています。したがって、wsimport コマンドを実行する前に、バインディング・ファイルを、PublisherRegistrationManager.wsdl ファイルが入っているディレクトリーにコピーする必要があります。 次は、ibm-wsn-jaxws.xml ファイルを含めるため の wsimport コマンドの実行方法の例です。
c:¥was¥bin¥wsimport -b ibm-wsn-jaxws.xml -keep PublisherRegistrationManager.wsdl

WS-Notification サービスが triggerActionNotSupportedFault を受け取る

バージョン 7.0 タイプの WS-Notification サービスに登録済みの JAX-WS 要求ベース・パブリッシャーを使用している場合、そのサービスがそのパブリッシャーの PausableSubscriptionManager インターフェースで何らかの操作を呼び出すと、パブリッシャーは triggerActionNotSupportedFault 例外メッセージで応答します。 このメッセージがトリガーされる操作は、Renew、Unsubscribe、PauseSubscription、または ResumeSubscription です。

以下のテキストと類似のメッセージは、サーバーの SystemOut.log ファイル内に示されます。 この例では、要求ベース・パブリッシャーからアンサブスクライブしようとしているブローカーに対する応答として障害メッセージがトリガーされます。

triggerActionNotSupportedFault triggerActionNotSupportedFault: messageContext: 
[MessageContext: logID=urn:uuid:13616A3EB4F278A3DC1221827497002] problemAction: 
http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeRequest

CWSJN1029W: エンドポイント Address[[xxx/prod_service/NotificationProducerPort]], ReferenceParams[] のリモート NotificationProducer で操作を実行しようとしましたが、操作を完了できませんでした。この操作は 2 秒で自動的に再試行されます。
操作は com.ibm.ws.sib.wsn.webservices.WSNWSException: のために失敗しました

CWSJN5035E: 内部エラーが発生しました。javax.xml.ws.soap.SOAPFaultException: The [action] cannot be processed at the receiver のために、エンドポイント参照 Address[[xxx/prod_service/PausableSubscriptionManagerPort]], ReferenceParams[] のリモート・パブリッシャーからアンサブスクライブできません

サーバーは引き続き、時間間隔を延長しながらパブリッシャーからのアンサブスクライブを試行し続けますが、それらは失敗します。

要求ベース・パブリッシャーの WSDL ファイルで SOAP アクション・パターンが指定されていない場合、デフォルトでは WS-Addressing がそれを 1 つ生成します。 パブリッシャーがそのバインディングに PausableSubscriptionManager ポート・タイプを使用する場合、WS-Addressing により生成されるデフォルトのアクション・パターンは、WS-Notification 仕様により定義されるアクションと一致しません。
注: この問題は、パブリッシャーが PausableSubscriptionManager ポート・タイプを使用する場合にのみ発生します。 パブリッシャーが SubscriptionManager ポート・タイプを使用する場合、WS-Addressing により生成されるデフォルトのアクション・パターンは、WS-Notification 仕様のそれと一致します。

この問題を解決するには、要求ベース・パブリッシャーの WSDL ファイルで、PausableSubscriptionManager インターフェースの各操作に使用する SOAP アクションを明示的に指定する必要があります。 各操作に使用するアクション URI は、Web サービス基本通知 1.3 (WS-BaseNotification) 仕様 (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn から入手可能) で定義されています。 例えば、この仕様でのアンサブスクライブ操作の WS-Addressing アクションは、http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeRequest で定義されており、パブリッシャー WSDL ファイル内ではアンサブスクライブ操作にこのアクションを使用する必要があります。 以下に、このような WSDL ファイルのバインディング・セクションの抜粋を示します。

<wsdl:binding name="PausableSubscriptionManagerBinding" type="wsn-bw:PausableSubscriptionManager">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />

<wsdl:operation name="Unsubscribe">
<soap:operation soapAction="http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeRequest" />

同様に、パブリッシャー WSDL ファイル内で、Renew、PauseSubscription、および ResumeSubscription の各操作に対しても対応するアクションを指定する必要があります。

ブローカー・サーバー・ログで「接続タイムアウト」エラーが示される

WebServicesFault( "Connection timed out" ) エラーが WS-Notification ブローカー・サーバー・ログに示され、WS-Notification サービスをサブスクライブしている多数のコンシューマーがいる場合は、サブスクライブ・コンシューマーにアウトバウンド通知メッセージを送信するときに、ブローカーが HTTP アウトバウンド・コネクター接続プールの最大接続数を超過してしまった可能性があります。

プールでアウトバウンド HTTP 接続の数を増やすには、ブローカーが実行しているサーバー上 (複数可) で com.ibm.websphere.webservices.http.maxConnection カスタム・プロパティーを設定します。 このプロパティーについて詳しくは、Web サービス・アプリケーションの HTTP トランスポート・カスタム・プロパティーを参照してください。

ブローカー・サーバー・ログで「メモリー不足」エラーが示される

「メモリー不足」エラーが WS-Notification ブローカー・サーバー・ログに示され、WS-Notification サービスをサブスクライブしている多数のコンシューマーがいる場合は、ブローカーが、実行しているサーバーに割り振られている使用可能な JVM ヒープ・サイズを超過してしまった可能性があります。

ブローカーが実行しているサーバー上 (複数可) の最大ヒープ・サイズを増やすには、IBM の Java 仮想マシンの調整を参照してください。

WebSphere Application Server バージョン 6.1 クライアント・アプリケーションが追加のエラー条件を処理する必要がある

WebSphere Application Server バージョン 6.1 では、WS-Notification のサポートは 、WS-Notification 規格の最終承認前公開レビュー・ドラフトに基づいています。 後続バージョンでは、このサポートが最終承認済みの規格をカバーするように拡張されました。WS-Notification の Public Review Draft と最終標準との違いは次のとおりです。
  • • UnableToGetMessagesFault という新しい障害条件が追加されました。これは、何らかの内部条件がメッセージを返すことができないことを意味する場合に、 GetMessages オペレーションへの要求に応答して返されます。 これは、返すメッセージがないケースとは異なることに注意してください。 返すメッセージがないケースは処理方法が異なり、発生する確率も高くなります。
  • • GetMessages オペレーションのスキーマでは、返すメッセージの数に対する値を渡す必要がなくなりました。値が渡されない場合は、使用可能なすべてのメッセージが返されます。 これは、値を提供するように既にコーディング済みのバージョン 6.1 のクライアント・アプリケーションには影響しません。
  • • DestroyPullPoint オペレーションは、既に宣言されている障害条件に加えて、ResourceUnknownFault 障害条件もスローするようになりました。

WebSphere Application Server バージョン 7.0 以降 に付属の WSDL およびスキーマ・ファイルは、最終のバージョン 1.3 WS-Notification 標準を反映するように更新されています。

既存の WS-Notification サービスを変更する必要はありません。 既存のクライアント・アプリケーションもそのまま引き続き使用できますが、 新しい WS-Notification サービスも使用していて、 それらのサービスに明示的に新しい障害条件を処理させる必要がある場合は、 新規サービスの WSDL ファイルを使用してクライアント・スタブを再生成してください。

SDO リポジトリーが正しく構成されていないために例外が発生する

バージョン 6.1 WS-Notification サービスを作成して、次のスタック・トレースを取得しようとしても、SDO リポジトリーが正しく構成されません。この問題を解決するには、SDO リポジトリーのインストールおよび構成を参照してください。

java.lang.Exception: com.ibm.ws.sib.webservices.admin.config.SIBConfigException: CWSWS5010E: 
Failed to store WSDL located at http://www.ibm.com/websphere/wsn/notification-broker 
due to the following exception: com.ibm.ws.sib.webservices.exception.SIBWSUnloggedException: 
CWSWS1007E: The following exception occurred: 
com.ibm.ws.sdo.config.repository.impl.RepositoryRuntimeException: 
javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0x0 No; 
nested exception is: org.omg.CORBA.TRANSACTION_ROLLEDBACK: 
javax.transaction.TransactionRolledbackException: ; nested exception is: 
javax.ejb.TransactionRolledbackLocalException: ; nested exception is: 
com.ibm.ws.ejbpersistence.utilpm.PersistenceManagerException: 
PMGR1014E: Exception occurred when getting connection factory: 
com.ibm.websphere.naming.CannotInstantiateObjectException: 
threw NameNotFoundException while the JNDI NamingManager was processing a 
javax.naming.Reference object. [Root exception is javax.naming.NameNotFoundException: 
Context: smeagolNode03Cell/nodes/smeagolNode03/servers/server1, name: 
jdbc/com.ibm.ws.sdo.config/SdoRepository: 
First component in name com.ibm.ws.sdo.config/SdoRepository not found. 
[Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: 
IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]] vmcid: 0x0 minor code: 0 completed: No.

各イベント通知で通知コンシューマーによって受信される複数のメッセージ

パブリッシャーによって通知ブローカーに挿入されたイベント通知の数よりも多い通知を、特定の通知コンシューマーで受信する場合が時々あります。 例えば、4 メッセージをパブリッシュし、通知コンシューマーで 8、12、16 (または、他の 4 の倍数) 個のメッセージを受信する場合があります。

通常、これは、通知コンシューマーをターゲットとする 2 つ以上のアクティブ・サブスクリプションがあることが原因となって起こり、サブスクライバー・アプリケーションが複数回実行される場合に発生します。サブスクライブ操作が呼び出されるたびに、新しいサブスクリプションが通知ブローカーによって作成される必要があります (Web サービス基本通知仕様のセクション 4.2 を参照)。以前のサブスクリプションが存在する場合は、重複するメッセージが配布される可能性があります。

これが発生中のものであるかをチェックするには、通知コンシューマーによって受信した通知の SubscriptionReference プロパティーを調べてください。 このエンドポイント参照には、通知を送信させるサブスクリプションの ID が含まれています。いくつかの異なるサブスクリプション ID を検索すると、複数のサブスクリプションがアクティブになっています。

サブスクライバー・アプリケーションは、サブスクリプションが不要な場合はタイディアップ (またはタイムアウトでそれらを登録) します。ただし、アクティブな WS-Notification サブスクリプションのリストまたは削除に記述されているように、ランタイム・パネルを使用して管理的にそれらをタイディアップすることもできます。

管理サブスクライバーとメッセージング・エンジンを削除するときに問題が発生することがある

管理サブスクライバーの削除

WS-Notification 管理サブスクライバーが構成されているバス・メンバーでメッセージング・エンジンを削除して再作成する場合、レコードが既に存在していないにもかかわらず、リモート Web サービス・サブスクリプションがアクティブのままになる (さらに通知メッセージがローカル・サーバーに送信される) ことがあるため、注意が必要です。

この状態を回避するには、WS-Notification 構成を削除するか、メッセージング・エンジンを削除する別のステップで管理サブスクライバーのみを削除します。動的構成更新が処理されるか、サーバーが再始動されると、リモート Web サービス・サブスクリプションが完全にタイディアップされます。

注: この問題は、変更対象が WS-Notification 構成のみの場合には起こりません。メッセージング・エンジンも削除される場合にのみ発生します。
クラスター内の管理サブスクライバー

クラスターからメッセージング・エンジンを削除する場合は、001 や 002 という番号のメッセージング・エンジンはあるが 000 という番号のものはない、というような状況を避けるために、番号の大きい順に削除してください。このようにするのは、クラスター内の最初に作成されたメッセージング・エンジンに特別な重要度を置く WS-Notification を使用する際に、問題が起きないようにするためです。

クラスター・トポロジーでは、 "バス・メンバー" (クラスター) 上で複数のメッセージング・エンジンを実行することができます。 管理サブスクライバーは、サービス・ポイント (バス・メンバー) に対して定義されるので、リモート Web サービスへのサブスクリプションを作成するメッセージング・エンジンを選択する際にいくつかの代替があります。 この状態では、クラスターの"最初の"メッセージング・エンジンがサブスクリプションを作成します。例えば、3 つのメッセージング・エンジンを含むクラスターでは、メッセージング・エンジンはパターン xxx-000-yyy、xxx-001-yyy、xxx-002-yyy の後に名前がきます。管理サブスクライバーのサブスクリプションは、"000" メッセージング・エンジンによって管理されます。

クラスターから "000" メッセージング・エンジンを削除してサーバーを再始動すると、管理対象のサブスクリプションが "001" メッセージング・エンジン (クラスター内の最も低い番号のエンジン) によって管理されるようになります。 ただし、上述のとおり、管理サブスクライバーが構成されているバス・メンバーでメッセージング・エンジンを削除および再作成すると、リモートの Web サービス・サブスクリプションは、レコードがなくてもアクティブのままです (通知メッセージをローカル・サーバーに送信します)。 したがって、後で別のメッセージング・エンジンがクラスターに追加され、xxx-000-yyy メッセージング・エンジンが現在定義されていない場合、新規エンジンが xxx-000-yyy の名前を使用します。したがって、このインスタンスでは、2 つのメッセージング・エンジンが並行して管理されたサブスクリプションを管理し、複数のサブスクリプションがリモートの Web サービスで行われる可能性があります。

メッセージング・エンジン xxx-000-yyy を再作成する必要があるような、起こりそうもないイベントでは、以下のステップを実行することにより管理されたサブスクリプションから重複するメッセージを回避することができます。
  • このクラスターに定義される管理済みサブスクリプションを削除します。
  • 既存のメッセージング・エンジンが、変更を監視できるようにします。これにより、クラスター内のメッセージング・エンジンが管理したと思われる管理済みサブスクリプションを削除します。
  • クラスター内に新規メッセージング・エンジンを作成します。
  • 管理されたサブスクリプションを再作成します。

バス宛先をバージョン 6.1 WS-Notification サービスで使用する場合の相違点

通常、バス宛先は、バス宛先に記述されているように使用されます。ただし、これはバージョン 6.1 WS-Notification サービスの場合には該当しません。バージョン 6.1 WS-Notification サービスと 関連付けられている宛先は、WS-Notification サービスが 要求を処理できるトピックに関連していないため、宛先を変更または仲介してはなりません。 WS-Notification では、トピックの構成はトピック名前空間で 処理されます。詳しくは、新規の WS-Notification 永続トピック名前空間の作成を参照してください。

バージョン 6.1 WS-Notification サービスを作成する場合、ウィザードにより、次の 3 つの WS-Notification サービスのロールごとに 1 つずつ、合わせて 3 つのサービス統合バスのインバウンド・サービスが WS-Notification サービスに対して構成されます。
  • 通知ブローカー
  • サブスクリプション・マネージャー
  • パブリッシャー登録マネージャー
これらのインバウンド・サービスは、バージョン 6.1 WS-Notification サービスと 同じサービス統合バス上で定義され、これらの各インバウンド・サービスは同じバスの宛先を参照します。

(アプリケーションからブローカーへの) インバウンド通知が失敗する

イベント通知をブローカーへパブリッシュしようとするアプリケーションは、通知操作を使用します。これは操作が完了できない場合、障害 (例外) を戻すことができないことを意味する片方向 (Web サービス) 操作として定義されます。このため、アプリケーションでは通知が成功したと見なされますが、サブスクライブ・アプリケーションでは、通知メッセージが受信されません。

通知が失敗するのは、アプリケーション・エラー (無効なトピック構文)、またはアプリケーション・コードとサーバー構成間の不一致 (未定義のトピック名前空間を使用) が原因である可能性があります。 インバウンド通知が失敗する特定の理由は、以下のとおりです。
  • トピックが無効: 提供されたトピック式が、指示されたダイアレクトの構文と一致しないか、サポートされていないダイアレクトを指定しています。これは、アプリケーション・エラーです。
  • トピック名前空間が無効: アプリケーションによって、構成されていないトピック名前空間が指定されていますが、管理者は、動的名前空間の使用を許可しないことを (WS-Notification サービスで) 指定しました。
  • トピックがサポートされていない: 指定されたトピックは、トピック名前空間に適用されたトピック名前空間文書によって禁止されています (例えば、"final" としてマークされているトピックのサブトピックです)。
  • クレデンシャルが無効: 指定されたユーザー ID またはパスワードが、無効であるか、必須権限を持っていません。これは、アプリケーション構成とサーバー・セキュリティー・ポリシー間の不一致によるエラーです。
  • パブリッシャーが登録されていない: アプリケーションがブローカーに最初に登録しないで通知を送信しようとしますが、WS-Notification サービスでは、管理者によってアプリケーションの登録を必要とするように構成されています。 これは、アプリケーション・エラーによって起こりました。正常に動作するアプリケーションは、ブローカーにパブリッシュする前に、登録する必要があるかどうか最初にチェックします。
  • 関連したサービス統合バス・トピック・スペースが、使用不可になっています。

サービス妨害攻撃を示している可能性があり、アプリケーションが正常に機能していないことを確実に示しているため、このタイプの例外は精密に監視する必要があります。特定の作成アプリケーションからのインバウンド通知が最初に失敗すると、警告メッセージがそのサーバーの SystemOut ログに送信されます。さらに、そのプロデューサーに通知障害がある場合は、後続の時刻指定警告メッセージが 30 分間隔でログに記録されます。 追加の情報が各時刻指定メッセージに提供され、30 分間隔でそのプロデューサーに受信された障害通知の数が示されます。

システムが各警告メッセージを生成すると、次の 2 つの ID のうちの 1 つを通して、作成アプリケーションが識別されます。
  • 通知操作で提供された通知メッセージの ProducerReference 要素。この要素は、アプリケーションを一意的に識別します。ただし、この要素はオプションです。
  • 要求を発信したホストの IP アドレス。このアドレスは、アプリケーションを一意的に識別しませんが、検索を絞り込みます。
注: システムでは、すべてのクラスのホスト IP アドレスを識別できません。例えば、SOAP over JMS トランスポートの場合、発信ホストの IP アドレスは使用不可であり不適切です。

(ブローカーからアプリケーションへの) アウトバウンド通知が失敗する

(ブローカーからアプリケーションへの) アウトバウンド Web サービス呼び出しは、リモート・アプリケーションを呼び出すことができない場合は成功しません。これは、アプリケーション障害、ネットワーク・エラー、またはファイアウォール構成問題の結果として起きる可能性があります。 サブスクライブするアプリケーションにイベント通知が渡されない場合、サーバー上で保持されるサブスクリプションについてのメッセージが作成されます。 特定のサブスクリプションに保持されたメッセージは、アクティブな WS-Notification サブスクリプションのリストまたは削除で説明しているように、ランタイム・パネルを使用して監視できます。 最新のイベント通知試行がこのように失敗したサブスクリプションは、WS-Notification サブスクリプション・ランタイム管理パネルで表示されるときに、「エラー」状態としてマーク付けされます。

WS-Notification サービス・ポイントが、NotificationConsumer アプリケーションへの正常な通知に失敗すると、警告メッセージがアプリケーション・サーバーの SystemOut ログに送信され、サブスクリプションが、2 分間待機するように告げられます。このタイプが失敗する理由は、リモート Web サービスが現在使用可能でないこと、またはネットワーク状態によって、ローカル・サーバーとサービス間の接続が妨げられることです。

2 分後に、通知が再試行されます。配信がまだ不可能であれば、サブスクリプションはさらに 2 分間待機状態に戻ります。障害が一過性の入出力エラーが原因の場合は、通知が正常に配信されるか、サブスクリプションが削除されるまで、このパターンが無制限に繰り返されます。 エラーの原因がリモート・サイドのアプリケーション障害の場合は、通知は、メッセージが受信されるサービス統合バス・トピック・スペース宛先の「最大デリバリー失敗数」設定で定義される回数まで再試行されます。最初の警告メッセージが SystemOut ログに出力された後、後続の時刻指定警告メッセージが 30 分間隔でログに記録されます。

自動削除されないステートフル・リソースのタイディアップ

ブローカーにサブスクライブするか、またはパブリッシャーを登録することによって、サーバーがアクティブなときにシステム・リソースを消費するステートフル・リソースをサーバー上で作成します。通常、アプリケーションは、これらのリソース作成の一環として終了時刻を指定し、終了時間に達すると、自動的に削除されます。ただし、アプリケーションが、リソースの無限な存続期間を要求することもできます。このことが行われると、アプリケーションが再度アクティブになり、リソースを使用 (または破棄) することがない場合でも、リソースは無期限にサーバー上に残る可能性があります。

ランタイムの WS-Notification との対話で説明しているように、ランタイム・パネルを使用して、ステートフル・リソース (サブスクリプションおよびパブリッシャーの登録) を表示できます。これらのパネルは、必要な場合には、項目を管理上削除する機能を提供します。リソースが削除された後に参照されると、アプリケーション障害を起こすことがあるので、アプリケーションがリソースを使用しなくなっている場合のみこれを行ってください。

WS-Notification によって作成された永続サブスクリプションをサービス統合バス・パネルの使用時に削除できない

WS-Notification アプリケーションを使用してサブスクリプションを作成したときに (つまり、サブスクライブ操作を使用)、1 つ以上の永続サブスクリプションが、関連サービス統合バス・トピック・スペース宛先で作成されます。これらの永続サブスクリプションは、パブリケーション・ポイントのサービス統合バス・ランタイム・パネルで表示することができます。

パブリケーション・ポイントのランタイム・パネルも、1 つ以上の永続サブスクリプションを削除する機能を提供します。ただし、WS-Notification アプリケーションによって作成されたサブスクリプションを削除するためにこの機能を使用すると、削除操作が失敗します。 WS-Notification 実装がサーバーが実行している期間の永続サブスクリプションのアクティブ・コンシューマーを保持しているため、アクティブ・コンシューマーが存在している場合には、永続サブスクリプションが削除されません。
注: この削除制限も他のアプリケーション (JMS アプリケーションなど) によって作成される永続サブスクリプションに適用されます。

WS-Notification アプリケーションによって作成されたサブスクリプションを削除するために、ランタイムの WS-Notification との対話で説明されているように、WS-Notification 実装によって提供されるランタイム・パネルを使用します。この方法によって、アクティブ・コンシューマーをクローズし、関連するサービス統合バス永続サブスクリプションを自動削除します。

メッセージング・エンジンの管理上の停止

WebSphere Application Server は、メッセージの送受信、および作成したさまざまな Web サービス・リソースの状態を作成したり取得するために、実行中のサービス統合バス・メッセージング・エンジンにアクセスできるかどうかによって異なります。

MBean インターフェースまたはランタイム・パネルを使用して、メッセージング・エンジンを停止することができます。これにより、WS-Notification が、メッセージング・エンジンの停止中に入ってくるアプリケーションからの要求を正常に処理できなくなります。 この状態では、(アプリケーションからブローカーへの) インバウンド通知が失敗するおよび(ブローカーからアプリケーションへの) アウトバウンド通知が失敗するで説明されているとおりにエラー・メッセージがログに記録されます。 メッセージング・エンジンを停止すると、すべての WS-Notification 処理が停止し、すべてのメッセージング・アプリケーションが機能しなくなります。メッセージング・エンジンを再始動すると、WS-Notification 処理が再開します。

トピック・スペースおよびトピック名前空間構成での変更の結果としての障害

WS-Notification 構成の成果物は、多くの場合、サーバー構成の他の領域で定義されたオブジェクトによって異なります。 例えば (バージョン 6.1 WS-Notification サービスの場合)、アプリケーション要求が受信されるエンドポイント・リスナー、およびメッセージが送受信されるサービス統合バス・トピック・スペースがあります。

次の項目は、WS-Notification ランタイム・コードによって取られるアクションについて説明します (アクションが、依存するオブジェクトでの関連する変更を満たす場合)。

サービス統合バス・トピック・スペースの削除

サービス統合バス・トピック・スペースは、WS-Notification が 実行時に依存している 1 次メッセージ・オブジェクトです。アプリケーションからの通知メッセージが、管理者が指定する (永続) トピック名前空間マッピングによって指定されたトピック・スペースにパブリッシュされます。

サービス統合バス・トピック・スペースを削除すると、新規および既存の WS-Notification アプリケーションに以下のような影響があります。
  • 削除されたトピック・スペースを参照する WS-Notification トピック名前空間を使用する RegisterPublisher 要求は、TopicNotSupportedFault エラー・メッセージを受信します。
  • 削除されたトピック・スペースに関連したトピックの通知要求は、メッセージをトピック・スペースにパブリッシュしません (削除されているため)。 通知操作によって障害がスローされないため、アプリケーションは通知されません ((アプリケーションからブローカーへの) インバウンド通知が失敗するを参照)。
  • 削除されたトピック名前空間を参照する WS-Notification トピック名前空間を使用するサブスクライブ要求は、SubscribeCreateFailedFault エラー・メッセージを受信します。
  • 削除されたトピック・スペースへの既存のサブスクリプションを持つアプリケーションへ、他のメッセージは配信されません。既存のサブスクリプションが削除され、サブスクリプションでの操作を呼び出そうとすると (例えば、getCreationTime)、ResourceUnknownFault エラー・メッセージが表示されます。
  • サービス統合バス・トピック・スペースの削除と再作成は、2 つの別個の手順として考えられています。既存のサブスクリプションは最初のステップに応じて削除されるため、トピック・スペースが再作成されると既存のサブスクリプションは存在しません。
永続トピック名前空間マッピングの削除

(現在アクティブな) サブスクリプションを確立するのに使用されたトピック名前空間マッピングを削除すると、前述した基本サービス統合バス・トピック・スペースを削除するときと同じ影響があり、この名前空間マッピングを使用して作成されたサブスクリプションが削除されます。

パブリッシャー登録および削除されたトピック名前空間マッピングに関連したプル・ポイントも削除されます。

永続トピック名前空間名前空間マッピングの変更

永続トピック名前空間名前空間マッピングのフィールドは、読み取り専用フィールドであるため、フィールドを "変更する" 唯一の方法は、名前空間マッピングを削除して、新規の値で再作成することです。永続トピック名前空間マッピングを削除する影響は、前の項目でも説明されています。

構成済みの SDO リポジトリーなしではバージョン 6.1 WS-Notification サービスを作成できない

バージョン 6.1 WS-Notification サービスを作成すると、WSDL 文書が SDO リポジトリーに保存されます。 SDO リポジトリーを正常に構成する前に管理コンソールまたはスクリプトを使用してバージョン 6.1 WS-Notification サービスを作成しようとすると、 以下の例外メッセージが表示されます。
java.lang.Exception: com.ibm.ws.sib.webservices.admin.config.SIBConfigException: CWSWS5010E: Failed to store WSDL located at http://www.ibm.com/websphere/wsn/notification-broker due to the following exception:
    com.ibm.ws.sib.webservices.exception.SIBWSUnloggedException: CWSWS1007E: The following exception
        occurred: com.ibm.ws.sdo.config.repository.impl.RepositoryRuntimeException:
        javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0x0 No; nested
        exception is: org.omg.CORBA.TRANSACTION_ROLLEDBACK:
        javax.transaction.TransactionRolledbackException:  ;
    nested exception is: javax.ejb.TransactionRolledbackLocalException: ;
    nested exception is: com.ibm.ws.ejbpersistence.utilpm.PersistenceManagerException: PMGR1014E: 
        Exception occurred when getting connection factory: 
        com.ibm.websphere.naming.CannotInstantiateObjectException: threw NameNotFoundException while 
        the JNDI NamingManager was processing a javax.naming.Reference object.
    [Root exception is javax.naming.NameNotFoundException: Context: KADGINNode01Cell/nodes/KADGINNode01/servers/server1, name: jdbc/com.ibm.ws.sdo.config/SdoRepository: First component in name com.ibm.ws.sdo.config/SdoRepository not found.
    [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: 
        IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]] vmcid: 0x0 minor code: 0 completed: No.
SDO リポジトリーの構成方法の詳細については、SDO リポジトリーのインストールおよび構成を参照してください。

インターネット・アクセスできない JAX-WS クライアントが WS-Notification サービスと通信しようと試みた場合に例外が発生する

クライアント・アプリケーションは通常、サービスの WSDL 部分を次の Web リンクに従って解決します。クライアントが稼働するマシンにインターネット・アクセスがない場合、次の例のような例外が発生します。
WSDLException (at /definitions/import[1]): faultCode=OTHER_ERROR: 
Unable to resolve imported document at 'http://docs.oasis-open.org/wsn/brw-2.wsdl', 
relative to 'http://localhost:9082/WSNService1WSNServicePt1NB/Service/WEB-INF/wsdl
/NotificationBroker.wsdl': java.net.UnknownHostException: docs.oasis-open.org

トピックWS-Notification サービスの WSDL が、Web リンクに従わずに解決されるよう JAX-WS クライアントを構成するの指示に従って、クライアントで WSDL ファイルのローカル・コピーが代わりに使用されるようにクライアントを構成します。


トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rjwsn_prob0
ファイル名:rjwsn_prob0.html