Tipps zur Fehlerbehebung bei WS-Notification

Tipps für die Fehlerbehebung beim WS-Notification-Publish/Subscribe-Messaging für Web-Services.

[z/OS]Verwenden Sie zum Identifizieren und Beheben von WS-Notification-Problemen die Trace- und Protokollierungsfunktionen von WebSphere Application Server gemäß der Beschreibung im Artikel Komponententrace (CTRACE) konfigurieren.

Zum Aktivieren des Trace für WS-Notification müssen Sie die Tracezeichenfolge des Anwendungsservers auf SIBWsn=all=enabled:com.ibm.ws.sib.webservices.*=all=enabled setzen. Wenn ein Fehler auftritt, den Sie für einen WS-Notification-Fehler halten, können Sie in der Administrationskonsole von WebSphere Application Server und in der Datei SystemOut.log des Anwendungsservers prüfen, ob Fehlernachrichten vorhanden sind. Sie können auch den Debug-Trace des Anwendungsservers aktivieren, um einen ausführlichen Ausnahmespeicherauszug zu erhalten.

Anmerkung: Dieser Artikel referenziert eine oder mehrere Protokolldateien des Anwendungsservers. Alternativ dazu wird empfohlen, den Server so zu konfigurieren, dass er die HPEL-Protokoll- und -Traceinfrastruktur (High Performance Extensible Logging) verwendet und nicht die Dateien SystemOut.log , SystemErr.log, trace.log und activity.log auf verteilten oder IBM® i-Systemen. Sie können HPEL auch in Verbindung mit Ihren nativen z/OS-Protokolleinrichtungen verwenden. Wenn Sie HPEL verwenden, können Sie mit dem Befehlszeilentool LogViewer im Verzeichnis "bin" des Serverprofils auf alle Ihre Protokoll- und Tracedaten zugreifen. Weitere Informationen zur Verwendung von HPEL finden Sie in der Dokumentation zum Einsatz von HPEL für die Fehlerbehebung in Anwendungen.

Eine Liste der wichtigsten bekannten Einschränkungen bei der Verwendung von WS-Notification finden Sie im Artikel WS-Notification: Bekannte Einschränkungen.

Systemnachrichten von WebSphere Application Server werden von vielen Quellen, einschließlich Komponenten und Anwendungen des Anwendungsservers, protokolliert. Nachrichten, die von Komponenten des Anwendungsservers sowie zugeordneten IBM Produkten protokolliert werden, beginnen mit einer eindeutigen Nachrichten-ID, die die Komponente oder Anwendung anzeigt, welche die Nachricht ausgegeben hat. Das Präfix für die Komponente WS-Notification lautet CWSJN.

Der Artikel Referenz zur Fehlerbehebung: Nachrichten enthält Informationen zu allen Nachrichten von WebSphere Application Server, die nach Nachrichtenpräfix indexiert sind. Zu jeder Nachricht finden Sie eine Beschreibung des Problems und Details zu Maßnahmen zur Behebung des Problems.

Die folgenden Tipps unterstützen Sie bei der Behebung häufig auftretender Probleme:

Eine JAX-WS-Anwendung, die ein Rohkonsument von Brokerbenachrichtigungen ist, muss eine SOAP-Aktion des Notification-Brokers erkennen

JAX-WS unterstützt die aktionsbasierte Zuteilung, und reine JAX-WS-Konsumentenanwendungen müssen den Aktions-URI http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify akzeptieren. Sie können dies auf die folgenden Arten aktivieren:
  • Ändern Sie die WSDL-Datei der Rohkonsumentenanwendung die SOAP-Bindungsinformationen so, dass sie den URI für die Benachrichtigungsaktion (notify) enthält:
    <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>
  • Ändern Sie die WSDL-Datei der Rohkonsumentenanwendung die Informationen zum Porttyp so, dass sie den URI für die Benachrichtigungsaktion (notify) enthält:
    <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>
  • Verwenden Sie eine JAX-WS-Annotation, um den Aktions-URI http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify im Anwendungscode anzugeben. Weitere Informationen finden Sie in der Beschreibung der Eigenschaft action der Annotation WebMethod im Artikel JAX-WS-Annotationen.

Die Datei "PublisherRegistrationManager.wsdl" wird von wsimport nur dann erfolgreich syntaktisch analysiert, wenn Sie eine JAX-WS-Bindungsdatei einschließen

Wenn Sie die WSDL-Dateien für eine WS-Notification-Anwendung in einer komprimierten Datei veröffentlichen und anschließend den Befehl "wsimport" für die Datei PublisherRegistrationManager.wsdl ausführen, wird die folgende Fehlernachricht angezeigt:
[ERROR] the following naming conflicts occurred: 
com.ibm.websphere.wsn.publisher_registration_manager.ResourceNotDestroyedFault
line 2 of file:/Pfad_der_WSDL/PublisherRegistrationManager.wsdl

Dieser Fehler tritt auf, weil die WSDL für den Publisher-Registrierungsmanager die Spezifikationen WS-Notification und WS-ResourceLifetime verwendet, die beide auf ein Element ResourceNotDestroyedFault verweisen, das denselben Nachrichtennamen verwendet. Im Folgenden finden Sie den relevanten Teil der WSDL-Datei des Publisher-Registrierungsmanagers:

  <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>

<!-- Einige Teile wurden übergangen -->

<!-- Auszug aus 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>

Zur Auflösung dieser Namensunverträglichkeit müssen Sie die JAX-WS-Bindungsdatei ibm-wsn-jaxws.xml als Argument für den Befehl "wsimport" angeben. Diese Bindungsdatei gewährleistet, dass die unverträglichen Elemente unterschiedlichen Klassennamen zugeordnet werden.

Die Datei ibm-wsn-jaxws.xml befindet sich im Verzeichnis Stammverzeichnis_des_Anwendungsservers/util, z. B. c:\was\util\ibm-wsn-jaxws.xml. Diese Bindungsdatei setzt das Vorhandensein der WSDL-Datei, auf die sie verweist, in ihrem eigenen Verzeichnis voraus. Bevor Sie also den Befehl wsimport ausführen, müssen Sie die Bindungsdatei in das Verzeichnis kopieren, das Ihre Datei PublisherRegistrationManager.wsdl enthält. Im Folgenden finden Sie ein Beispiel für die Ausführung des Befehls wsimport zum Einfügen der Datei ibm-wsn-jaxws.xml:
c:\was\bin\wsimport -b ibm-wsn-jaxws.xml -keep PublisherRegistrationManager.wsdl

WS-Notification-Service empfängt triggerActionNotSupportedFault

Sie haben einen bedarfsbasierten JAX-WS-Publisher bei einem WS-Notification-Service der Version 7.0 registriert. Wenn der Service Operationen in der Schnittstelle "PausableSubscriptionManager" des Publishers aufruft, antwortet der Publisher mit einer Ausnahmenachricht des Typs "triggerActionNotSupportedFault". Die Operationen, die diese Nachricht auslösen, sind Renew, Unsubscribe, PauseSubscription und ResumeSubscription.

Es werden Nachrichten wie die folgenden in der Datei "SystemOut.log" für den Server angezeigt. In diesem Beispiel wird die Fehlernachricht als Reaktion auf den Versuch des Brokers, die Subskription beim bedarfsbasierten Publisher aufzuheben, ausgelöst.

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

CWSJN1029W: Der Versuch, eine Operation für einen fernen NotificationProducer am Endpunkt Address[[xxx/prod_service/NotificationProducerPort]], ReferenceParams[] durchzuführen, ist fehlgeschlagen. Diese Operation wird automatisch in 2 Sekunden wiederholt.
Die Operation ist aufgrund der folgenden Ausnahme fehlgeschlagen: com.ibm.ws.sib.wsn.webservices.WSNWSException:

CWSJN5035E: Es ist ein interner Fehler aufgetreten. Die Subskription beim fernen Publisher an der Endpunktreferenz Address[[xxx/prod_service/PausableSubscriptionManagerPort]], ReferenceParams[] kann wegen der folgenden Ausnahme nicht aufgehoben werden: The [action] cannot be processed at the receiver.

Der Server setzt die nicht erfolgreichen Versuche, die Subskriptionen beim Publisher aufzuheben, in immer größer werdenden Zeitabständen fort.

Wenn die WSDL-Datei für Ihren bedarfsbasierten Publisher kein SOAP-Aktionsmuster angibt, generiert WS-Addressing standardmäßig ein Beispiel. Wenn Ihr Publisher den Porttyp "PausableSubscriptionManager" für seine Bindung verwendet, stimmt das von WS-Addressing generierte Standardaktionsmuster nicht mit den in der Spezifikation "WS-Notification" definierten Aktionen überein.
Anmerkung: Dieses Problem tritt nur auf, wenn Ihr Publisher den Porttyp "PausableSubscriptionManager" verwendet. Wenn Ihr Publisher den Porttyp "SubscriptionManager" verwendet, stimmen die von WS-Addressing generierten Standardaktionsmuster mit denen in der Spezifikation "WS-Notification" überein.

Zur Behebung dieses Problems müssen Sie in der WSDL-Datei für Ihren bedarfsbasierten Publisher explizit die SOAP-Aktion angeben, die für jede der Operationen in der Schnittstelle "PausableSubscriptionManager" verwendet werden soll. Der für jede Operation zu verwendende Aktions-URI ist in der Spezifikation "Web Services Base Notification 1.3 (WS-BaseNotification)" definiert, die Sie auf der Webseite "http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn" finden. Die WS-Addressing-Aktion für die Operation "Unsubscribe" ist beispielsweise in der Spezifikation als http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeRequest definiert. Deshalb müssen Sie diese Aktion für die Operation "Unsubscribe" in der WSDL-Datei Ihres Publishers verwenden. Im Folgenden finden Sie einen Auszug aus dem Bindungsabschnitt einer solchen WSDL-Datei:

<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" />

Auf ähnliche Weise müssen Sie die entsprechenden Aktionen für die Operationen Renew, PauseSubscription und ResumeSubscription in der WSDL-Datei Ihres Publishers angeben.

Fehler des Typs "Überschreitung des Verbindungszeitlimits" in den Broker-Serverprotokollen

Wenn Fehler des Typs WebServicesFault("Überschreitung des Verbindungszeitlimits") in den Serverprotokollen Ihres WS-Notification-Brokers aufgezeichnet werden und sehr viele Konsumenten Ihren WS-Notification-Service subskribiert haben, hat der Broker möglicherweise die maximal zulässige Verbindungsanzahl im Verbindungspool für abgehende HTTP-Verbindungen beim Senden abgehender Benachrichtigungen an subskribierte Konsumenten überschritten.

Wenn Sie die Anzahl abgehender HTTP-Verbindungen im Pool erhöhen möchten, setzen Sie die angepasste Eigenschaft com.ibm.websphere.webservices.http.maxConnection in den Servern, in denen Ihr Broker ausgeführt wird. Weitere Informationen zu dieser Eigenschaft finden Sie im Artikel Angepasste HTTP-Transporteigenschaften für Web-Service-Anwendungen.

Fehler des Typs "Speicherkapazität erschöpft" in den Broker-Serverprotokollen

Wenn Fehler des Typs "Speicherkapazität erschöpft" in den Serverprotokollen Ihres WS-Notification-Brokers aufgezeichnet werden und sehr viele Konsumenten Ihren WS-Notification-Service subskribiert haben, hat der Broker möglicherweise die verfügbare Größe des JVM-Heapspeichers, die dem Server, in dem er ausgeführt wird, zugeordnet ist, überschritten.

Wenn Sie die maximale Größe des Heapspeichers für die Server, in denen der Broker ausgeführt wird, erhöhen möchten, lesen Sie den Artikel IBM Virtual Machine for Java optimieren.

Clientanwendungen der WebSphere Application Server Version 6.1 müssen die zusätzlichen Fehlerbedingungen handhaben

In WebSphere Application Server Version 6.1 basiert die Unterstützung für WS-Notification auf einem noch nicht endgültig genehmigten öffentlichen Überarbeitungsentwurf der WS-Notification-Standards. In höheren Versionen wurde die Unterstützung erweitert und basiert auf den endgültig genehmigten Standards. Die Unterschiede z wischen den öffentlichen Überarbeitungsentwürfen von WS-Notification und den endgültigen Standards sind im Folgenden beschrieben:
  • • Es wurde eine neue Fehlerbedingung mit dem Namen "UnableToGetMessagesFault" hinzugefügt. Diese Fehlerbedingung wird als Antwort auf eine Anforderung an die Operation "GetMessages" zurückgegeben, wenn eine interne Bedingung bedeutet, dass keine Nachrichten zurückgegeben werden können. Beachten Sie bitte, dass dies nicht gleichbedeutend ist, dass keine Nachrichten für die Rückgabe vorhanden sind. Diese Fehlerbedingung wird anders behandelt und tritt wahrscheinlich eher auf.
  • • Das Schema für die Operation "GetMessages" erfordert nicht mehr, dass ein Wert für die Anzahl zurückzugebender Nachrichten übergeben werden muss. Wenn kein Wert übergeben wird, werden alle verfügbaren Nachrichten zurückgegeben. Dies hat keine Auswirkungen auf Clientanwendungen der Version 6.1, die bereits für die Bereitstellung eines Werts codiert sind.
  • • Die Operation "DestroyPullPoint" löst jetzt zusätzlich zu den zuvor deklarierten Fehlerbedingungen die Fehlerbedingung "ResourceUnknownFault" aus.

Die WSDL- und Schemadateien, die mit WebSphere Application Server Version 7.0 oder höher geliefert werden, wurden an die endgültigen WS-Notification-Standards der Version 1.3 angepasst.

Sie müssen Ihre vorhandenen WS-Notification-Services nicht ändern. Die vorhandenen Clientanwendungen funktionieren weiterhin unverändert, aber wenn sie jetzt auch mit neuen WS-Notification-Services arbeiten und die neuen Fehlerbedingungen explizit behandeln sollen, müssen Sie die Client-Stubs unter Verwendung der WSDL-Datei aus dem neuen Service erneut generieren.

Ausnahme aufgrund einer nicht ordnungsgemäßen Konfiguration des SDO-Repositorys

Wenn Sie beim Versuch, einen WS-Notification-Service der Version 6.1 zu erstellen, den folgenden Stack-Trace erhalten, dann ist das SDO-Repository nicht ordnungsgemäß konfiguriert. Informationen zum Beheben dieses Problems finden Sie im Artikel SDO-Repository installieren und konfigurieren.

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: Die folgende Ausnahme ist eingetreten:
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: Ausnahme beim Abrufen der Verbindungsfactory:
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.

Ein Benachrichtigungskonsument empfängt mehrere Nachrichten für jede Ereignisbenachrichtigung

In manchen Situationen werden auf einem bestimmten Benachrichtigungskonsumenten möglicherweise mehr Notification-Broker als Ereignisbenachrichtigungen von einem Publisher auf einem Notification-Broker eingefügt wurden. Beispielsweise werden 4 Nachrichten veröffentlicht, aber an dem Benachrichtigungskonsumenten werden 8, 12, 16 (oder ein anderes Vielfaches von vier) Nachrichten empfangen.

Dies wird normalerweise dadurch verursacht, dass zwei oder mehr aktive Subskriptionen vorhanden sind, die sich an denselben Benachrichtigungskonsumenten richten - eine Situation, die dann eintreten kann, wenn die Subskribentenanwendungen mehr als einmal ausgeführt wird. Jedesmal, wenn die Subscribe-Operation aufgerufen wird, muss eine neue Subskription vom Notification-Broker erstellt werden (siehe Abschnitt 4.2 der Spezifikation Web Services Base Notification), sodass Nachrichten mehrfach zugestellt werden, wenn bereits eine Subskription vorhanden ist.

Um festzustellen, ob dies der Fall ist, prüfen Sie die Eigenschaft SubscriptionReference der Benachrichtigungen, die vom Benachrichtigungskonsumenten empfangen werden. Diese Endpunktreferenz enthält die ID der Subskription, die das Senden der Benachrichtigung ausgelöst hat. Falls Sie mehrere unterschiedliche Subskriptions-IDs finden, dann sind mehrere Subskriptionen aktiv.

Subskribentenanwendungen sollten Subskriptionen bereinigen, die nicht benötigt werden (oder diese mit einem Zeitlimit registrieren). Sie können sie jedoch auch im Rahmen der Verwaltungstätigkeit bereinigen, indem Sie die Laufzeitanzeigen wie in Artikel Aktive WS-Notification-Subskriptionen auflisten oder löschen beschrieben verwenden.

Beim Löschen verwalteter Subskribenten und Messaging-Engines können Probleme auftreten

Verwaltete Subskribenten löschen

Gehen Sie beim Löschen und erneuten Erstellen von Messaging-Engines in Busmembern, für die verwaltete WS-Notification-Subskribenten konfiguriert wurden, vorsichtig vor, da dies in einigen Fällen dazu führen kann, dass die Subskription des fernen Web-Service aktiv bleibt (und Benachrichtigungen an den lokalen Server weitergibt), selbst wenn kein Datensatz für die Subskription mehr vorhanden ist.

Zur Vermeidung einer solchen Situation sollten Sie die WS-Notification-Konfiguration oder lediglich die verwalteten Subskribenten separat von der Messaging-Engine löschen. Wenn die dynamische Konfigurationsaktualisierung anschließend verarbeitet oder der Server erneut gestartet wird, dann wird die ferne Web-Service-Subskription ordnungsgemäß bereinigt.

Anmerkung: Dieses Problem tritt nicht auf, wenn lediglich die WS-Notification-Konfiguration geändert wurde. Es tritt nur dann auf, wenn auch die Messaging-Engine gelöscht wurde.
Verwaltete Subskribenten in einem Cluster

Wenn Sie Messaging-Engines aus einem Cluster entfernen, entfernen Sie sie in absteigender numerischer Reihenfolge entfernen, um zu verhindern, dass es beispielsweise Messaging-Engines mit dem Nummern 001 und 002, aber keine mit der Nummer 000 gibt. Damit sollen Probleme vermieden werden, wenn Sie die Spezifikation "WS-Notification", die der ersten erstellten Messaging-Engine in einem Cluster eine besondere Signifikanz zuweist.

In einer Clustertopologie können mehrere Messaging-Engines im "Busmember" (Cluster) ausgeführt werden. Verwaltete Subskribenten werden für einen Servicepunkt (Busmember) definiert, daher gibt es mehrere Alternativen bei der Auswahl der Messaging-Engine, die für das Erstellen der Subskription für den fernen Web-Service zuständig ist. In dieser Situation ist die "erste" Messaging-Engine im Cluster für das Erstellen der Subskription zuständig. Beispiel: In einem Cluster mit drei Messaging-Engines werden für die Messaging-Engines Namen verwendet, die dem Beispiel xxx-000-yyy, xxx-001-yyy, xxx-002-yyy entsprechen, und die Subskriptionen der verwalteten Subskribenten werden von der Messaging-Engine "000" gesteuert.

Wenn Sie die Messaging-Engine "000" aus dem Cluster löschen und die Server anschließend erneut starten, dann werden die verwalteten Subskriptionen anschließend von der Messaging-Engine "001", der Engine mit der niedrigsten Nummer im Cluster, gesteuert. Wie bereits erwähnt, kann die ferne Web-Service-Subskription jedoch weiterhin aktiv bleiben (und Benachrichtigungen an den lokalen Server übermitteln), wenn Messaging-Engines auf Busmembern, für die verwaltete Subskribenten konfiguriert sind, gelöscht und erneut erstellt werden, obwohl kein Eintrag mehr dafür existiert. Wenn daher zu einem späteren Zeitpunkt eine weitere Messaging-Engine zum Cluster hinzugefügt wird und derzeit keine Messaging-Engine mit dem Namen "xxx-000-yyy" definiert ist, dann verwendet die neue Engine den Namen "xxx-000-yyy". In diesem Fall ist es möglich, dass zwei Messaging-Engines existieren, die beide annehmen, dass sie für die Steuerung der verwalteten Subskription zuständig sind, sodass mehrere Subskriptionen für den fernen Web-Service stattfinden.

Für den unwahrscheinlichen Fall, dass die Messaging-Engine xxx-000-yyy erneut erstellt werden muss, können Sie durch folgende Vorgehensweise vermeiden, dass eine verwaltete Subskription mehrere Nachrichten erzeugt:
  • Löschen Sie die verwalteten Subskriptionen, die für diesen Cluster definiert sind.
  • Ermöglichen Sie den vorhandenen Messaging-Engines die Überwachung der Änderungen. Daraufhin löschen die Messaging-Engines im Cluster die verwalteten Subskriptionen, für deren Verwaltung sie sich zuständig fühlen.
  • Erstellen Sie die neue Messaging-Engine im Cluster.
  • Erstellen Sie die verwalteten Subskriptionen erneut.

Bei der Verwendung von Buszielen mit WS-Notification-Services der Version 6.1 treten Differenzen auf

Gewöhnlich wird ein Busziel verwendet, wie im Artikel Busziele beschrieben. Dies ist bei WS-Notification-Services der Version 6.1 jedoch nicht der Fall. Das dem WS-Notification-Service der Version 6.1 zugeordnete Ziel bezieht sich nicht auf die Topics, für die der WS-Notification-Service Anforderungen verarbeiten kann. Sie sollten das Ziel nicht ändern oder vermitteln. In WS-Notification erfolgt die Konfiguration von Topics über Topic-Namespaces. Weitere Informationen finden Sie im Artikel Einen neuen permanenten WS-Notification-Topic-Namespace erstellen.

Wenn Sie einen WS-Notification-Service der Version 6.1 erstellen, konfiguriert der Assistent drei SIB-Services für eingehende Daten für den WS-Notification-Service, einen für jede drei Rollen des WS-Notification-Service:
  • NotificationBroker
  • SubscriptionManager
  • PublisherRegistrationManager
Diese Services für eingehende Daten werden in demselben Service Integration Bus wie der WS-Notification-Service der Version 6.1 definiert, und jeder dieser Services für eingehende Daten verweist auf dasselbe Busziel.

Eine eingehende Benachrichtigung (von der Anwendung an den Broker) ist nicht erfolgreich

Anwendungen, die Ereignisbenachrichtigungen im Broker veröffentlichen möchten, verwenden die Operation "notify". Diese Operation ist als Einwegoperation (Web-Service-Operation) definiert, d. h., falls die Operation nicht ausgeführt werden kann, kann kein Fehler (keine Ausnahme) zurückgegeben werden. Daher wird die Anwendung annehmen, dass die Benachrichtigung erfolgreich war, obwohl die subskribierenden Anwendungen die Benachrichtigung nicht empfangen.

Die Benachrichtigung ist möglicherweise nicht erfolgreich, weil ein Anwendungsfehler (ungültige Topicsyntax) aufgetreten ist oder eine Abweichung zwischen Anwendungscode und Serverkonfiguration (Verwendung eines nicht definierten Topic-Namespace) festgestellt wurde. Im Folgenden sind verschiedene Gründe für das Scheitern eingehender Benachrichtigungen aufgeführt:
  • Das Topic ist nicht gültig. Der angegebene Topicausdruck entspricht nicht der Syntax des angegebenen Dialekts, oder es wurde ein nicht unterstützter Dialekt angegeben. Dies ist ein Anwendungsfehler.
  • Der Topic-Namespace ist nicht gültig: Die Anwendung gibt einen nicht konfigurierten Topic-Namespace an, aber der Administrator hat (im WS-Notification-Service) festgelegt, dass die Verwendung dynamischer Namespaces nicht zulässig ist.
  • Topic wird nicht unterstützt: Die Verwendung des angegebenen Topic wird in einem Topic-Namespace-Dokument, das auf den Topic-Namespace angewendet wurde, untersagt (z. B. handelt es sich um ein untergeordnetes Topic eines Topic, das als "final" (endgültig) gekennzeichnet wurde).
  • Berechtigungsnachweise nicht gültig: Die angegebene Benutzer-ID oder das angegebene Kennwort ist nicht gültig oder hat nicht die erforderliche Berechtigung. Dies wird durch eine Abweichung zwischen der Anwendungskonfiguration und den Serversicherheitsrichtlinien verursacht.
  • Publisher nicht registriert: Die Anwendung versucht, eine Benachrichtigung zu senden, ohne sich vorher beim Broker zu registrieren, obwohl der Administrator den WS-Notification-Service so konfiguriert hat, dass dieser die Registrierung der Anwendungen erfordert. Dies wird durch einen Anwendungsfehler verursacht. Eine ordnungsgemäß konfigurierte Anwendung sollte zunächst prüfen, ob eine Registrierung erforderlich ist, bevor sie Veröffentlichungen auf einem Broker vornimmt.
  • Der zugehörige SIB-Topicbereich (Service Integration Bus) wurde inaktiviert.

Dieser Ausnahmetyp muss genau überwacht werden, weil sie auf eine Denial-of-Service-Attacke hinweisen kann, und weil sie auf jeden Fall anzeigt, dass die Anwendung nicht ordnungsgemäß funktioniert. Wenn eine eingehende Benachrichtigung einer bestimmten Erzeugeranwendung zum ersten Mal fehlschlägt, wird eine Warnung an das Protokoll SystemOut des Servers gesendet. Falls weitere Benachrichtigungen für diesen Erzeuger fehlschlagen, werden nachfolgende zeitverzögerte Warnungen in Abständen von 30 Minuten protokolliert. Mit jeder zeitverzögerten Nachricht werden zusätzliche Informationen bereitgestellt, die angeben, wie viele fehlgeschlagene Benachrichtigungen für den betreffenden Erzeuger während des 30-minütigen Intervalls empfangen wurden.

Wenn das System eine Warnung generiert, identifiziert es die Erzeugeranwendung mit einer von zwei IDs:
  • Mit dem Element ProducerReference der NotifyMessage, das in der Operation Notify angegeben wird. Durch dieses Element wird eine Anwendung eindeutig gekennzeichnet. Allerdings ist es optional.
  • Die IP-Adresse des Hosts, der die Anforderung generiert hat. Diese Adresse ist nicht unbedingt eine eindeutige Kennzeichnung der Anwendung, aber sie grenzt die Suche ein.
Anmerkung: Das System kann die Host-IP-Adresse nicht immer feststellen. Für SOAP-over-JMS-Transporte ist die IP-Adresse des Hosts, der die Anforderung generiert hat, beispielsweise nicht verfügbar oder nicht anwendbar.

Abgehende Benachrichtigung (vom Broker an die Anwendung) ist nicht erfolgreich

Das Fehlschlagen eines abgehenden Web-Server-Aufrufs (vom Broker an die Anwendung) wird dadurch ausgelöst. dass eine ferne Anwendung nicht aufgerufen werden kann, und kann das Ergebnis eines Anwendungsfehlers, eines Netzfehlers oder eines Firewall-Konfigurationsproblems sein. Wenn Ereignisbenachrichtigungen nicht an subskribierte Anwendungen übergeben werden, kommt es zu einer Anhäufung von Nachrichten für die Subskriptionen im Server. Die Nachrichten zu einer bestimmten Subskription können über die Laufzeitanzeigen wie im Artikel Aktive WS-Notification-Subskriptionen auflisten oder löschen beschrieben angezeigt werden. Subskriptionen, für die die letzte Ereignisbenachrichtigung auf diese Weise fehlgeschlagen ist, werden als im Status ERROR (Fehler) befindlich gekennzeichnet, wenn Sie in der Verwaltungsanzeige für die Laufzeit der WS-Notification-Subskription angezeigt werden.

Falls die Benachrichtigung einer NotificationConsumer-Anwendung durch den WS-Notification-Servicepunkt fehlschlägt, wird eine Warnung an das Protokoll SystemOut des Anwendungsservers gesendet und der Subskription wird mitgeteilt, dass sie 2 Minuten warten muss. Ein möglicher Grund für einen Fehler dieser Art ist der, dass der ferne Web-Service derzeit nicht verfügbar ist oder dass die Netzbedingungen den Kontakt zwischen dem lokalen Server und dem Service verhindern.

Nach 2 Minuten wird die Benachrichtigung abgerufen. Falls eine Zustellung weiterhin unmöglich ist, wird die Subskription für weitere 2 Minuten in einen Wartestatus zurückversetzt. Falls der Fehler durch einen vorübergehenden E/A-Fehler verursacht wird, dann wird diese Vorgehensweise so lange wiederholt, bis die Benachrichtigung erfolgreich übermittelt wird oder bis die Subskription gelöscht wird. Falls der Fehler durch einen Anwendungsfehler auf der fernen Seite verursacht wird, dann wird so lange versucht, die Benachrichtigung zu übermitteln, wie in der Einstellung "Maximale Anzahl fehlgeschlagener Zustellungen" des SIB-Topicbereichsziels, von dem die Nachricht empfangen wird, angegeben ist. Nachdem die erste Warnung an das Protokoll SystemOut ausgegeben wurde, werden nachfolgende zeitverzögerte Warnungen in Abständen von 30 Minuten protokolliert.

Statusabhängige Ressourcen bereinigen, die nicht automatisch gelöscht werden

Die Subskription beim Broker oder die Registrierung beim Publisher erzeugt auf dem Server eine statusabhängige Ressource, die Systemressourcen belegt, solange sie aktiv ist. Normalerweise legt eine Anwendung eine Beendigungszeit für diese Ressourcen fest, wenn sie sie erstellt. Daher werden die Ressourcen beim Erreichen dieser Beendigungszeit automatisch gelöscht. Die Anwendung kann für die Ressourcen jedoch auch eine unbegrenzte Lebensdauer anfordern. In diesem Fall können Ressourcen unbegrenzt auf dem Server bleiben, selbst dann, wenn die Anwendung nie wieder darauf zurückgreifen wird, um sie zu verwenden (oder löschen).

Sie können die statusabhängigen Ressourcen (Subskriptionen und Publisher-Registrierungen) in den Laufzeitanzeigen, die im Artikel Interaktion mit WS-Notification zur Laufzeit beschrieben werden, anzeigen. Diese Anzeigen bieten auch die Möglichkeit, die Ressourcen gegebenenfalls administrativ zu löschen. Führen Sie diesen Schritt nur dann aus, wenn Sie sicher sind, dass die Anwendung die Ressource nicht mehr verwenden wird, da andernfalls Anwendungsfehler auftreten, wenn die Ressource nach dem Löschen referenziert wird.

Eine von WS-Notification erstellte permanente Subskription kann in der Anzeige für den Service Integration Bus nicht gelöscht werden

Wenn Sie eine Subskription mit einer WS-Notification-Anwendung erstellen, d. h. mit der Operation 'Subscribe', dann werden im relevanten SIB-Topicbereichsziel ein oder mehrere permanente Subskriptionen erstellt. Diese permanenten Subskriptionen können in den Laufzeitanzeigen des Service Integration Bus (SIB) für den Veröffentlichungspunkt angezeigt werden.

Die Laufzeitanzeigen für den Veröffentlichungspunkt bieten auch die Möglichkeit zum Löschen einer oder mehrerer permanenter Subskriptionen. Wenn Sie diese Funktion jedoch zum Löschen einer Subskription verwenden, die von einer WS-Notification-Anwendung erstellt wurde, dann scheitert die Löschoperation. Dieses Scheitern der Löschoperation wird dadurch verursacht, dass die WS-Notification-Implementierung während der Laufzeit des Servers einen aktiven Konsumenten für diese permanente Subskription bereithält. Eine permanente Subskription kann jedoch nicht gelöscht werden, wenn ein aktiver Konsument vorhanden ist.
Anmerkung: Diese Einschränkung beim Löschen gilt auch für permanente Subskriptionen, die von anderen Anwendungen z. B. von JMS-Anwendungen erstellt wurden.

Verwenden Sie die im Artikel Interaktion mit WS-Notification zur Laufzeit beschriebenen Laufzeitanzeigen, die von der WS-Notification-Implementierung bereitgestellt werden, um eine Subskription zu löschen, die von einer WS-Notification-Anwendung erstellt wurde. Bei dieser Vorgehensweise wird der aktive Konsument geschlossen und die zugehörigen permanenten SIB-Subskriptionen werden gelöscht.

Administrativer Stopp einer Messaging-Engine

WebSphere Application Server muss in der Lage sein, auf eine aktive SIB-Messaging-Engine zuzugreifen, um Nachrichten zu senden und zu empfangen und um den Status der verschiedenen Web-Service-Ressourcen, die erstellt werden, zu erstellen und abzurufen.

Sie können eine Messaging-Engine stoppen, die die MBean-Schnittstelle oder Laufzeitanzeigen verwendet. Dadurch wird verhindert, dass WS-Notification die Anforderungen von Anwendungen, die während des Stopps der Messaging-Engine ankommen, erfolgreich bedienen kann. In dieser Situation werden Fehlernachrichten wie in den Artikeln Eine eingehende Benachrichtigung (von der Anwendung an den Broker) ist nicht erfolgreich und Abgehende Benachrichtigung (vom Broker an die Anwendung) ist nicht erfolgreich beschrieben protokolliert. Wenn Sie eine Messaging-Engine stoppen, wird die gesamte WS-Notification-Verarbeitung gestoppt und alle Messaging-Anwendungen funktionieren nicht mehr. Wenn Sie die Messaging-Engine erneut starten, wird die WS-Notification-Verarbeitung wiederaufgenommen.

Fehler infolge von Änderungen im Topicbereich und in Topicbereichskonfigurationen

Die WS-Notification-Konfigurationsartefakte sind häufig abhängig von Objekten, die in anderen Bereichen der Serverkonfiguration definiert sind. Beispiele hierfür sind die Endpunktlistener (in WS-Notification-Services der Version 6.1), über die die Anwendungsanforderungen empfangen werden, und die SIB-Topicbereiche in die und von denen Nachrichten gesendet werden.

Im Folgenden werden die Aktionen beschrieben, die der WS-Notification-Laufzeitcode ausführt, wenn er relevante Änderungen in den Objekten findet, von denen er abhängig ist.

Löschen eines SIB-Topicbereichs

Der SIB-Topicbereich ist das primäre Messaging-Objekt, nach dem sich WS-Notification zur Laufzeit richtet.Die Benachrichtigungen einer Anwendung werden in dem Topicbereich veröffentlicht, der in der durch den Administrator festgelegten Zuordnung des (permanenten) Topic-Namespace angegeben wird.

Das Löschen eines SIB-Topicbereichs hat für neue und vorhandene WS-Notification-Anwendungen folgende Auswirkungen:
  • An RegisterPublisher-Anforderungen, die einen WS-Notification-Topic-Namespace verwenden, der den gelöschten Topicbereich referenziert, wird eine Fehlernachricht des Typs "TopicNotSupportedFault" zurückgegeben.
  • Notify-Anforderungen für ein Topic, das dem gelöschten Topicbereich zugeordnet ist, veröffentlichen die Nachricht nicht im Topicbereich (weil er gelöscht wurde). Die Anwendung wird darüber nicht informiert, weil die Operation 'Notify' keine Fehler zurückgibt (siehe den Artikel Eine eingehende Benachrichtigung (von der Anwendung an den Broker) ist nicht erfolgreich).
  • An Subscribe-Anforderungen, die einen WS-Notification-Topic-Namespace verwenden, der den gelöschten Topicbereich referenziert, wird eine Fehlernachricht vom SubscribeCreateFailedFault zurückgegeben.
  • An die Anwendungen, die vorhandene Subskriptionen für den gelöschten Topicbereich besitzen, werden keine weiteren Nachrichten zurückgegeben. Die vorhandene Subskription wird gelöscht, und alle Versuche, Operationen für die Subskription aufzurufen (z. B. getCreationTime), lösen die Fehlernachricht ResourceUnknownFault aus.
  • Das Löschen und erneute Erstellen eines SIB-Topicbereichs werden als zwei separate Schritte betrachtet. Vorhandene Subskriptionen werden infolge des ersten Schrittes gelöscht und sind daher nicht vorhanden, wenn der Topicbereich erneut erstellt wird.
Löschen der Zuordnung eines permanenten Topic-Namespace

Wird die Topic-Namespace-Zuordnung gelöscht, die zum Erstellen einer (derzeit aktiven) Subskription verwendet wurde, hat dies dieselbe Wirkung wie das weiter oben beschriebene Löschen des zugrunde liegenden SIB-Topicbereichs, und die Subskriptionen, die unter Verwendung dieser Namespace-Zuordnung erstellt wurden, werden gelöscht.

Publisher-Registrierungen und Pull-Punkte, die mit der gelöschten Topic-Namespace-Zuordnung verknüpft waren, werden ebenfalls gelöscht.

Änderung der Zuordnung eines permanenten Topic-Namespace

Die Felder für die Zuordnung eines permanenten Topic-Namespace sind schreibgeschützte Felder. Daher können sie nur dann "geändert" werden, wenn die Namespace-Zuordnung gelöscht und mit neuen Werten erstellt wird. Die Auswirkungen, die das Löschen der Zuordnung eines permanenten Topic-Namespace zur Folge hat, werden im vorherigen Abschnitt beschrieben.

Das Erstellen eines WS-Notification-Service der Version 6.1 ohne konfiguriertes SDO-Repository scheitert

Wenn Sie einen WS-Notification-Service der Version 6.1 erstellen, werden die WSDL-Dokumente im SDO-Repository gespeichert. Falls Sie versuchen, einen WS-Notification-Service der Version 6.1 über die Administrationskonsole oder über Scripting zu erstellen, bevor Sie das SDO-Repository erfolgreich konfiguriert haben, wird die folgende Ausnahmenachricht angezeigt.
java.lang.Exception: com.ibm.ws.sib.webservices.admin.config.SIBConfigException: CWSWS5010E: Die WSDL an Position http://www.ibm.com/websphere/wsn/notification-broker konnte wegen der folgenden Ausnahme nicht gespeichert werden:
    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: 
        Ausnahme beim Abrufen der Verbindungsfactory:
        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.
Einzelheiten zum Konfigurieren des SDO-Repository finden Sie im Artikel SDO-Repository installieren und konfigurieren.

Ausnahme beim Versuch eines JAX-WS-Clients, der keinen Internetzugriff hat, versucht, eine Verbindung zu einem WS-Notification-Service herzustellen

Die Clientanwendung löst die WSDL-Teile für den Service gewöhnlich über die folgenden Web-Links auf. Wenn die Maschine, auf der der Client ausgeführt wird, keinen Internetzugriff hat, tritt eine Ausnahme ähnlich der folgenden ein:
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

Konfigurieren Sie den Client so, dass er stattdessen eine lokale Kopie der WSDL-Datei verwendet. Verwenden Sie dazu die Anweisungen im Artikel JAX-WS-Client zum Auflösen einer WS-Notification-Service-WSDL ohne Verfolgung von Web-Links konfigurieren.


Symbol, das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rjwsn_prob0
Dateiname:rjwsn_prob0.html