Tipps zur Fehlerbehebung bei WS-Notification
Tipps für die Fehlerbehebung beim WS-Notification-Publish/Subscribe-Messaging für Web-Services.
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.
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.
- Eine JAX-WS-Anwendung, die ein Rohkonsument von Brokerbenachrichtigungen ist, muss eine SOAP-Aktion des Notification-Brokers erkennen
- Die Datei "PublisherRegistrationManager.wsdl" wird von wsimport nur dann erfolgreich syntaktisch analysiert, wenn Sie eine JAX-WS-Bindungsdatei einschließen
- WS-Notification-Service empfängt triggerActionNotSupportedFault
- Fehler des Typs "Überschreitung des Verbindungszeitlimits" in den Broker-Serverprotokollen
- Fehler des Typs "Speicherkapazität erschöpft" in den Broker-Serverprotokollen
- Clientanwendungen der WebSphere Application Server Version 6.1 müssen die zusätzlichen Fehlerbedingungen handhaben
- Ausnahme aufgrund einer nicht ordnungsgemäßen Konfiguration des SDO-Repositorys
- Ein Benachrichtigungskonsument empfängt mehrere Nachrichten für jede Ereignisbenachrichtigung
- Beim Löschen verwalteter Subskribenten und Messaging-Engines können Probleme auftreten
- Bei der Verwendung von Buszielen mit WS-Notification-Services der Version 6.1 treten Differenzen auf
- Eine eingehende Benachrichtigung (von der Anwendung an den Broker) ist nicht erfolgreich
- Abgehende Benachrichtigung (vom Broker an die Anwendung) ist nicht erfolgreich
- Statusabhängige Ressourcen bereinigen, die nicht automatisch gelöscht werden
- Eine von WS-Notification erstellte permanente Subskription kann in der Anzeige für den Service Integration Bus nicht gelöscht werden
- Administrativer Stopp einer Messaging-Engine
- Fehler infolge von Änderungen im Topicbereich und in Topicbereichskonfigurationen
- Das Erstellen eines WS-Notification-Service der Version 6.1 ohne konfiguriertes SDO-Repository scheitert
- Ausnahme beim Versuch eines JAX-WS-Clients, der keinen Internetzugriff hat, versucht, eine Verbindung zu einem WS-Notification-Service herzustellen
Eine JAX-WS-Anwendung, die ein Rohkonsument von Brokerbenachrichtigungen ist, muss eine SOAP-Aktion des Notification-Brokers erkennen
- Ä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
[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.
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.
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
- • 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.
- NotificationBroker
- SubscriptionManager
- PublisherRegistrationManager
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.
- 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.
- 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.
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.
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
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
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.