Conseils relatifs à l'identification et la résolution des incidents liés à WS-Notification

Conseils pour l'identification et la résolution des incidents liés à vos services Web de messagerie de publication/abonnement WS-Notification.

[z/OS]Pour faciliter l'identification et la résolution des incidents liés à WS-Notification, utilisez les fonctions de trace et de consignation de WebSphere Application Server, comme indiqué dans Configuration du service de trace des composants (CTRACE).

Pour activer la fonction de trace pour WS-Notification, affectez à la chaîne de trace du serveur d'applications la valeur SIBWsn=all=enabled:com.ibm.ws.sib.webservices.*=all=enabled. Si vous rencontrez un incident qui semble être lié à WS-Notification, vous pouvez vérifier si la console d'administration de WebSphere Application Server et le fichierSystemOut.log du serveur d'applications contiennent des messages d'erreur. Vous pouvez également activer la trace de débogage du serveur d'applications pour fournir un vidage détaillé des exceptions.

Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications.

Une liste des principales limitations connues s'appliquant lors de l'utilisation de WS-Notification est fournie dans WS-Notification : Limitations connues.

Les messages système WebSphere Application Server sont journalisés à partir de nombreuses sources, y compris les applications et composants de serveur d'applications. Les messages consignés par les composants de serveur d'applications et les produits IBM associés commencent par un identificateur de message unique qui indique le composant ou l'application à l'origine du message. Le préfixe du composant WS-Notification est CWSJN.

Le document Troubleshooter reference: Messages contient des informations sur tous les messages WebSphere Application Server, indexés par préfixe de message. Une explication de l'incident et des détails sur les éventuelles actions à entreprendre pour résoudre l'incident sont fournis pour chaque message.

Cette rubrique contient un ensemble de conseils permettant d'identifier et de résoudre les incidents courants :

Une application JAX-WS, client de notifications par courtier, doit reconnaître une action SOAP de courtier de notification

JAX-WS prend en charge la répartition basée sur des actions et les applications client JAX-WS doivent accepter l'URI d'action http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify. Pour ce faire, procédez de l'une des manières suivantes :
  • Dans le fichier WSDL de l'application client, modifiez les informations de liaison SOAP pour qu'elles contiennent l'URI de l'action de notification :
    <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>
  • Dans le fichier WSDL de l'application client, modifiez les informations de type de port pour qu'elles contiennent l'URI de l'action de notification :
    <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>
  • Utilisez une annotation JAX-WS pour spécifier l'URI de l'action http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify dans le code de l'application. Pour plus d'informations, voir la propriété action de l'annotation WebMethod dans la rubrique Annotations JAX-WS.

Le fichier PublisherRegistrationManager.wsdl n'est pas correctement analysé par wsimport sauf si vous ajoutez un fichier de liaison JAX-WS

Lorsque vous publiez les fichiers WSDL pour une application WS-Notification dans un fichier compressé et que vous exécutez la commande wsimport sur le fichier PublisherRegistrationManager.wsdl, le message d'erreur suivant s'affiche :
[ERROR] the following naming conflicts occurred: 
com.ibm.websphere.wsn.publisher_registration_manager.ResourceNotDestroyedFault
line 2 of file:/chemin_vers_wsdl/PublisherRegistrationManager.wsdl

Cette erreur se produit car le WSDL du gestionnaire d'enregistrement du diffuseur de publication utilise à la fois les spécifications de WS-Notification et de WS-ResourceLifetime ; qui font référence à un élément ResourceNotDestroyedFault partageant le même nom de message. Ci-après une partie pertinente du fichier WSDL du gestionnaire d'enregistrement du diffuseur de publication :

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

<!-- Certaines parties ont été omises -->

<!-- Extrait de 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>

Pour résoudre ce conflit de désignation, vous devez ajouter le fichier de liaison JAX-WS ibm-wsn-jaxws.xml en tant qu'argument à la commande wsimport. Ce fichier de liaison garantit que les éléments en conflit sont mappés avec différents noms de classe.

Le fichier ibm-wsn-jaxws.xml se trouve dans le répertoire racine_serveur_app/util. Par exemple : c:\was\util\ibm-wsn-jaxws.xml. Ce fichier de liaison s'attend à trouver le fichier WSDL auquel il fait référence dans son propre répertoire ; avant d'exécuter la commande wsimport, vous devez donc copier ce fichier de liaison dans le même répertoire que le fichier PublisherRegistrationManager.wsdl. Voici comment exécuter la commande wsimport pour inclure le fichier ibm-wsn-jaxws.xml :
c:\was\bin\wsimport -b ibm-wsn-jaxws.xml -keep PublisherRegistrationManager.wsdl

Le service WS-Notification reçoit une erreur triggerActionNotSupportedFault

Vous disposez d'un diffuseur de publication basé sur des demandes JAX-WS enregistré avec un type de service WS-Notification version 7.0. Lorsque le service appelle l'une des opérations sur l'interface PausableSubscriptionManager du diffuseur de publications, ce dernier répond avec un message d'exception triggerActionNotSupportedFault. Les opérations à l'origine de ce message sont Renew, Unsubscribe, PauseSubscription et ResumeSubscription.

Vous voyez apparaître des messages similaires au texte suivant dans le fichier SystemOut.log du serveur. Dans cet exemple, l'erreur est renvoyée en réponse à la tentative d'annulation d'abonnement du courtier du diffuseur de publication basé sur des demandes.

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

CWSJN1029W: An attempt was made to perform an operation on a remote NotificationProducer located with endpoint Address[[xxx/prod_service/NotificationProducerPort]], ReferenceParams[] but the operation could not be completed. Cette opération sera 
relancée automatiquement dans 2 secondes. 
The operation failed due to com.ibm.ws.sib.wsn.webservices.WSNWSException: 

CWSJN5035E: Une erreur interne s'est produite : Impossible de se désabonner du diffuseur distant 
à l'adresse de référence de noeud final [[xxx/prod_service/PausableSubscriptionManagerPort]], 
ReferenceParams[] en raison d'une exception javax.xml.ws.soap.SOAPFaultException: 
The [action] cannot be processed at the receiver.

Le serveur tente en vain d'annuler l'abonnement du diffuseur de publication selon des intervalles de temps de plus en plus courts.

Lorsque le fichier WSDL de votre diffuseur de publication basé sur les demandes n'indique pas de modèle d'action SOAP, le serveur WS-Addressing en génère un par défaut. Si votre diffuseur de publication utilise le type de port PausableSubscriptionManager pour sa liaison, les modèles d'action par défaut générés par WS-Addressing ne correspondent pas aux actions définies par la spécification WS-Notification.
Remarque : Cet incident ne se produit que si votre diffuseur de publication utilise le type de port PausableSubscriptionManager. Si votre diffuseur de publication utilise le type de port SubscriptionManager, les modèles d'action par défaut générés par WS-Addressing correspondent à ceux de la spécification WS-Notification.

Pour résoudre cet incident, dans le fichier WSDL de votre diffuseur de publication basé sur les demandes, vous devez indiquez explicitement l'action SOAP à utiliser pour chacun des opérations de l'interface PausableSubscriptionManager. L'URI de l'action à utiliser pour chaque opération est défini dans la spécification de notification de base des services Web 1.3 (WS-BaseNotification) disponible à l'adresse http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn Par exemple, l'action WS-Addressing de l'opération Unsubscribe est définie dans la spécification par http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeRequest, et vous devez donc utiliser cette action pour l'opération Unsubscribe dans le fichier WSDL de votre diffuseur de publication. Voici un extrait de la section de liaison d'un tel fichier 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" />

De même, vous devez indiquer les actions correspondantes pour les opérations Renew, PauseSubscription et ResumeSubscription dans le fichier WSDL de votre diffuseur de publication.

Il existe des erreurs de "délai de connexion" dans les journaux serveur de votre courtier

Si vous constatez des erreurs WebServicesFault("Délai de connexion") dans les journaux serveur de votre courtier WS-Notification et qu'un grand nombre de clients est abonné à votre service WS-Notification, le courtier a probablement dépassé le nombre maximum de connexions dans le pool de connexion du connecteur sortant HTTP lors de l'envoi de messages de notification sortants aux abonnés.

Pour augmenter le nombre de connexions HTTP sortantes du pool, définissez la propriété personnalisée com.ibm.websphere.webservices.http.maxConnection du ou des serveurs sur lesquels votre courtier est exécuté. Pour plus d'informations sur cette propriété, voir Propriétés personnalisées de transport HTTP pour les applications de services Web.

Il existe des erreurs de "mémoire insuffisante" dans les journaux serveur de votre courtier

Si vous constatez des erreurs "Mémoire insuffisante" dans les journaux serveur de votre courtier WS-Notification et qu'un grand nombre de clients est abonné à votre service WS-Notification, le courtier a probablement dépassé la taille de tas maximale de la JVM disponible et allouée au serveur sur lequel il est exécuté.

Pour augmenter la taille de tas maximale du ou des serveurs sur lesquels votre courtier est exécuté, voir Optimisation de la machine virtuelle IBM pour Java.

Les applications client WebSphere Application Server Version 6.1 doivent gérer des conditions d'erreur supplémentaires

En WebSphere Application Server Version 6.1, la prise en charge de WS-Notification repose sur un document provisoire contenant les normes WS-Notification. Dans les versions suivantes, cette prise en charge est étendue pour couvrir les normes finales validées. Les différences entre les avant-projets de révision publics WS-Notification et les dernières normes sont les suivantes :
  • • Une nouvelle condition d'erreur appelée UnableToGetMessagesFault a été ajoutée. Elle est renvoyée en réponse à une demande adressée à une opération GetMessages si une condition interne indique qu'il est impossible de renvoyer des messages. Elle doit se différencier de l'erreur signalant qu'il n'y a pas de messages à renvoyer. Dans ce cas, l'erreur est traitée différemment et représente un cas plus courant.
  • • Le schéma de l'opération GetMessages ne requiert plus la transmission d'une valeur pour le nombre de messages à renvoyer. Si aucune valeur n'est transmise, tous les messages disponibles sont renvoyés. Cela n'a pas d'incidence sur les applications client Version 6.1, qui sont déjà codées pour fournir une valeur.
  • • L'opération DestroyPullPoint génère désormais la condition d'erreur ResourceUnknownFault en plus des erreurs précédemment déclarées.

Le fichier WSDL et les fichiers schéma fournis avec WebSphere Application Server Version 7.0 ou ultérieures sont mis à jour pour prendre en compte les normes finales de WS-Notification version 1.3.

Il n'est pas nécessaire de modifier les services WS-Notification existants. Les applications client existantes continuent à fonctionner telles quelles mais si vous utilisez également les nouveaux services WS-Notification et que vous souhaitez qu'ils gèrent explicitement les nouvelles erreurs, régénérez les services et les modules de remplacement client à l'aide du fichier WSDL du nouveau service.

Une exception se produit car le référentiel SDO n'est pas configuré correctement

Si vous tentez de créer un service WS-Notification version 6.1, et que vous obtenez la trace de pile suivante, alors le référentiel SDO n'est pas configuré correctement. Pour résoudre cet incident, voir Installation et configuration du référentiel 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.

Plusieurs messages sont reçus en provenance d'un client de notification pour chaque notification d'événements

Dans certaines situations, vous pouvez recevoir plus de notifications pour un client de notification donné que le nombre de notifications d'événements qui a été inséré dans le courtier de notification par un diffuseur de publications. Par exemple, vous pouvez publier 4 messages, et en recevoir 8, 12, 16 (ou autres multiples de quatre) au niveau du client de notification.

En règle générale, cela provient de la présence de deux ou plusieurs abonnements actifs qui cible le destinataire de notification, une situation qui peut se produire si l'application de l'abonné est lancée plus d'une fois. Chaque fois que l'opération Subscribe est appelée, un nouvel abonnement doit être créé par le courtier de notification (voir section 4.2 de la spécification de la notification de base des services Web), qui entraîne la distribution des doubles des messages si un abonnement précédent existe.

Pour vérifier que cela fonctionne, vérifiez la propriété RéférenceAbonnement des notifications reçues par le destinataire de notification. Cette référence d'extrémité contient l'identificateur de l'abonnement qui provoque l'envoi de la notification. Vous trouvez plusieurs identificateurs différents si plusieurs abonnements sont actifs.

Les applications d'abonné doivent mettre de l'ordre dans les abonnements lorsqu'ils ne sont pas requis (ou les enregistrer avec un délai d'attente) ; cependant, vous pouvez les classer de façon administrative à l'aide des panneaux d'exécution comme décrit dans Affichage ou suppression des abonnements WS-Notification actifs.

Des incidents peuvent survenir lors de la suppression des moteurs de messagerie et des abonnés administrés

Suppression des abonnés administrés

Supprimez et récréez avec précaution les moteurs de messagerie sur les membres du bus pour lesquels des abonnés gérés par WS-Notification ont été configurés car dans certains cas, cette action peut laisser actif l'abonnement aux services Web distants (et transmettre les messages de notification au serveur local), même si son enregistrement n'existe plus.

Pour éviter cette situation, vous devez supprimer la configuration WS-Notification, ou simplement les abonnés administrés, dans une étape séparée pour supprimer le moteur de messagerie. Quand la mise à jour de la configuration dynamique est effectuée ou que le serveur a redémarré, l'abonnement au service Web à distance est organisé correctement.

Remarque : Cet incident ne se produit pas en cas de modification uniquement de la configuration WS-Notification ; il survient uniquement si le moteur de messagerie est également supprimé.
Abonnés administrés dans un cluster

Lorsque vous supprimez les moteurs de messagerie d'un cluster, vous devez les supprimer dans l'ordre numérique du plus haut au plus bas pour éviter par exemple une situation dans laquelle des moteurs de messagerie sont numérotés 001 et 002 et pas 000. Cette précaution permet d'éviter les incidents si vous utilisez WS-Notification, qui accorde une importance particulière au premier moteur de messagerie créé dans un cluster.

Dans une topologie en cluster, plusieurs moteurs de messagerie peuvent s'exécuter sur le "membre de bus" (cluster). Les abonnés administrés sont définis sur un point de service (membre de bus) et, par conséquent, plusieurs alternatives existent pour choisir le moteur de messagerie chargé de créer l'abonnement au service Web distant. Dans cette situation, le "premier" moteur de messagerie du cluster est en charge de la création de l'abonnement. Par exemple, si un cluster contient trois moteurs de messagerie, ils auront tous les trois des noms de type xxx-000-yyy, xxx-001-yyy, xxx-002-yyy, et les abonnements de l'abonné administré seront gérés par le moteur de messagerie "000".

Si vous supprimez le moteur de messagerie "000" du cluster et que vous redémarrez les serveurs, les abonnements gérés par l'administrateur sont désormais gérés par le moteur de messagerie "001", qui correspond au numéro de moteur le plus bas du cluster. Toutefois, comme mentionné précédemment, la suppression et la recréation de moteurs de messagerie dans les membres du bus pour lesquels les abonnés administrés ont été configurés peuvent laisser actif l'abonnement aux services Web distants (et transmettre les messages de notification au serveur local), même s'il n'existe plus d'enregistrement qui leurs sont associés. Par conséquent, si un autre moteur de messagerie est ajouté ultérieurement au cluster et qu'aucun moteur de messagerie xxx-000-yyy n'est défini, le nouveau moteur prend le nom xxx-000-yyy. Par conséquence, dans ce cas, il est possible que deux moteurs de messagerie puissent déterminer simultanément qu'ils gèrent l'abonnement, ce qui crée plusieurs abonnements au service Web distant.

Si par hasard vous deviez créer de nouveau un moteur de messagerie xxx-000-yyy, vous pouvez éviter de reproduire des messages d'un abonnement géré par l'administrateur en procédant comme suit :
  • Supprimer les abonnements gérés par l'administrateur définis dans ce cluster.
  • Autoriser les moteurs de messagerie existants à observer la modification. En conséquence, les moteurs de messagerie du cluster suppriment les abonnements gérés par l'administrateur qu'ils pensent gérer.
  • Créer le nouveau moteur de messagerie dans le cluster.
  • Créer de nouveau les abonnements gérés par l'administrateur.

Il existe des différences si vous utilisez des destinations de bus avec des services WS-Notification version 6.1

En règle générale, une destination de bus peut être utilisée comme décrit dans Destinations de bus. Cependant, ce n'est pas le cas pour les services WS-Notification version 6.1. Cette destination qui est associée au service WS-Notification version 6.1 est sans relation avec les sujets pour lesquels le service WS-Notification peut gérer des demandes. Vous ne devez donc pas modifier la destination ou la soumettre à une médiation. Dans WS-Notification, la configuration des sujets s'effectue via des espaces de nom de sujet. Pour plus d'informations, voir Création d'un espace de nom de sujet WS-Notification permanent.

Si vous créez un service WS-Notification version 6.1, l'assistant configure trois services entrants de bus d'intégration de services pour le service WS-Notification, un pour chacun des trois rôles de service WS-Notification :
  • Courtier de notifications
  • Gestionnaire d'abonnements
  • Gestionnaire d'enregistrements du diffuseur de publications
Ces services entrants sont définis dans le même bus d'intégration de services que le service WS-Notification version 6.1. Chacun d'eux fait référence au même bus d'intégration de services.

Une notification entrante (application vers courtier) échoue

Les applications devant publier des notifications d'événements au courtier se servent de l'opération Notify. Cette dernière est définie comme une opération (serfvices Web) unidirectionnelle, ce qui signifie qu'il est impossible de retourner un défaut (exception) s'il est impossible de terminer l'opération. Cette dernière est définie comme une opération (services services) unidirectionnelle, ce qui signifie qu'il est impossible de retourner une erreur (exception) s'il est impossible de terminer l'opération. Ainsi, l'application suppose que la notification a réussi, mais les applications d'abonnement ne reçoivent pas le message de notification.

La notification peut échouer en raison d'une erreur d'application (syntaxe de sujet incorrecte), ou d'une non-concordance entre le code d'application et la configuration du serveur (utilisant un espace de nom de sujet non défini). Les raison spécifiques pour lesquelles une notification entrante peut échouer sont les suivantes :
  • Le sujet est incorrect : l'expression du sujet fournie ne correspond pas à la syntaxe du langage indiqué ou elle indique un langage non pris en charge. Il s'agit d'une erreur d'application.
  • L'espace de nom de sujet est incorrect : l'application indique un espace de nom de sujet qui n'est pas configuré, mais l'administrateur a spécifié (sur le service WS-Notification) que l'utilisation des espaces de nom dynamiques n'est pas autorisée.
  • Le sujet n'est pas pris en charge : le sujet indiqué est interdit par un document d'espace de nom de sujet qui a été appliqué à l'espace de nom de sujet (il s'agit d'une sous-rubrique d'un sujet qui a été définie comme "finale", par exemple).
  • Les autorisations d'accès sont incorrectes : l'ID utilisateur ou le mot de passe indiqué n'est pas valide ou ne dispose pas des droits requis. Cette erreur est due à une non-concordance entre la configuration de l'application et les règles de sécurité du serveur.
  • Le diffuseur de publication n'est pas enregistré : l'application tente d'envoyer une notification alors qu'elle n'est pas enregistrée auprès du courtier, et l'administrateur a configuré le service WS-Notification pour que l'enregistrement des applications soit obligatoire. Il s'agit d'une erreur d'application ; une application qui se comporte bien commence par vérifier si l'enregistrement préalable est obligatoire avant d'envoyer une publication à un courtier.
  • L'espace de sujet du bus d'intégration du service associé a été désactivé.

Vous devez surveiller de près ce type d'exception car il peut indiquer un refus de service à une attaque et indiquer également que l'application ne fonctionne probablement pas correctement. Au premier échec d'une notification entrante de l'application émettrice, un message d'avertissement est envoyé au journal SystemOut du serveur. En cas d'incidents multiples pour cet expéditeur, les messages d'avertissement temporisés ultérieurs sont consignés par intervalles de 30 minutes. Des informations complémentaires sont fournies avec chaque message temporisé pour indiquer le nombre d'échecs de notifications qui a été reçu pour cet expéditeur au cours de l'intervalle de 30 minutes.

Quand le système génère chaque message d'avertissement, il identifie l'application émettrice à l'aide de l'un des deux identificateurs :
  • L'élément ProducerReference du message NotifyMessage fourni par l'opération Notify. Cet élément identifie l'application de manière unique. Toutefois, cet élément reste facultatif.
  • L'adresse IP de l'hôte qui a généré la requête. Cette adresse risque de ne pas identifier l'application de manière unique, mais elle limite votre recherche.
Remarque : L'identification de l'adresse IP de l'hôte par le système n'est pas systématique. Par exemple, pour le protocole SOAP sur les transferts JMS, l'adresse IP de l'hôte émetteur n'est pas disponible ou applicable.

Une notification sortante (courtier vers application) échoue

Un appel de service Web sortant (courtier vers application) échoue lorsqu'une application distante est indisponible pour l'appel. Ceci peut provenir d'un échec de l'application, d'une erreur réseau ou d'un incident dans la configuration du pare-feu. Lorsque des notifications d'événements ne sont pas transmises aux applications abonnées, des messages sont générés sur les abonnements conservés sur le serveur. Les messages concernant un abonnement peuvent être visualisés à l'aide des panneaux d'exécution comme décrit dans Affichage ou suppression des abonnements WS-Notification actifs. Les abonnements pour lesquels la tentative de notification d'événements la plus récente a échoué de cette manière sont indiqués par un état ERROR lorsqu'ils s'affichent dans le panneau d'administration d'exécution de l'abonnement à WS-Notification.

Si le point de service WS-Notification ne parvient pas à notifier correctement une application NotificationConsumer, un message d'avertissement est envoyé au journal SystemOut du serveur d'applications et l'abonnement reçoit l'instruction de patienter 2 minutes. Les raisons d'un incident de ce type peuvent provenir de l'indisponibilité actuelle du service Web distant ou des conditions du réseau qui empêchent le contact entre le serveur local et le service.

Après 2 minutes, une nouvelle notification est relancée. Si la distribution est toujours impossible, l'abonnement est alors mis en état d'attente pour 2 minutes supplémentaires. Si l'incident provient d'une erreur E-S non résidente, ce modèle est répété indéfiniment, jusqu'à ce que la notification soit distribuée correctement ou que vous supprimiez l'abonnement. Si l'erreur provient de l'échec d'une application du côté éloigné, la notification sera relancée autant de fois que ce qui est défini dans le paramètre "Nombre maximal d'échecs de la distribution" de la destination de l'espace de sujet du bus d'intégration de services qui envoie le message. Après la sortie du premier message d'avertissement du journal SystemOut, les messages d'avertissement temporisés ultérieurs sont consignés par intervalles de 30 minutes.

Nettoyage des ressources avec état qui ne sont pas automatiquement supprimées

L'action de s'abonner à un courtier ou d'enregistrer un diffuseur de publications crée une ressource avec état sur le serveur qui consomme les ressources du système quand il est actif. En règle générale, une application indique une date de résiliation dans le cadre de la création de ces ressources, et, par conséquent, elles sont automatiquement quand la date de résiliation est atteinte. Toutefois, il est également possible pour l'application de demander une durée de vie infinie pour la ressource. Dans ce cas, les ressources sont conservées indéfiniment sur le serveur même si l'application risque de ne plus utiliser (ou de détruire) les ressources.

Vous pouvez afficher les ressources avec état (abonnements et enregistrements des diffuseurs) à l'aide des panneaux d'exécution décrits dans Interaction lors de l'exécution avec WS-Notification. Ces panneaux fournissent également la possibilité de supprimer de manière administrative les éléments, le cas échéant. Assurez-vous que l'application n'utilise plus ces ressources avant de le faire, pour éviter tout incident de l'application causé par l'utilisation d'une ressource après sa suppression.

Un abonnement durable qui a été créé par WS-Notification ne peut pas être supprimé lors de l'utilisation du panneau du bus d'intégration de services

Lorsque vous créez un abonnement à partir d'une application WS-Notification, autrement dit à l'aide de l'opération Subscribe, un ou plusieurs abonnements durables sont créés dans la destination appropriée d'espace de sujet du bus d'intégration de services. Vous pouvez afficher ces abonnements durables dans les panneaux d'exécution du bus d'intégration de services du point de publication.

Les panneaux d'exécution du point de publication permettent également de supprimer un ou plusieurs abonnements durables. Toutefois, la suppression échoue si vous utilisez cette fonction pour supprimer un abonnement qui a été créé par une application WS-Notification. Ceci se produit car l'implémentation WS-Notification conserve un client actif pour cet abonnement durable pendant toute la durée du fonctionnement du serveur et un abonnement durable ne peut pas être supprimé si un client actif est présent.
Remarque : Cette restriction relative à la suppression s'applique également aux abonnements durables créés par d'autres applications, telles que des applications JMS.

Vous pouvez supprimer un abonnement créé par une application WS-Notification à l'aide des panneaux d'exécution fournis par l'implémentation WS-Notification, comme décrit dans Interaction lors de l'exécution avec WS-Notification. Cette approche ferme le client actif et supprime automatiquement les abonnements durables du bus d'intégration de services connexes.

Arrêt administratif d'un moteur de messagerie

WebSphere Application Server doit pouvoir accéder à un moteur de messagerie du bus d'intégration de services actif pour envoyer et recevoir des messages, et pour créer et extraire l'état des diverses ressources de service Web qui sont créées.

Vous pouvez arrêter un moteur de messagerie à l'aide de l'interface MBean ou des panneaux d'exécution. Cette action empêche WS-Notification de répondre correctement aux requêtes des applications qui peuvent arriver au cours du processus d'arrêt du moteur de messagerie. Dans ce cas, les messages d'erreur sont consignés selon la procédure décrite aux sections Une notification entrante (application vers courtier) échoue et Une notification sortante (courtier vers application) échoue. Lors de l'arrêt d'un moteur de messagerie, le traitement WS-Notification s'arrête et toutes les applications de messagerie cessent de fonctionner. Quand vous redémarrez le moteur de messagerie, le traitement WS-Notification reprend.

Echecs provenant de modifications effectuées sur les configurations des espaces de nom de sujet et des espace de sujet

Les artefacts de la configuration WS-Notification dépendent souvent des objets définis à d'autres endroits de la configuration de serveur. Par exemple (pour les services WS-Notification version 6.1), les modules d'écoute de noeud final par lequel les requêtes d'application sont reçues et les espaces de sujets du bus d'intégration de services vers et depuis lesquels les messages sont envoyés.

Les éléments suivants décrivent l'action prise par le code d'exécution WS-Notification quand il rencontre des modifications importantes dans les objets dont il dépend.

Suppression d'un espace de sujet du bus d'intégration de services

L'espace de sujet du bus d'intégration de services est l'objet messagerie principal dont dépend WS-Notification en phase d'exécution. Les messages de notification d'une application sont publiés dans l'espace de sujets indiqué par le mappage d'espace de nom de sujet (permanent) indiqué par l'administrateur.

La suppression d'un espace de sujet du bus d'intégration de services engendre les effets suivants sur les nouvelles applications et les applications existantes WS-Notification :
  • Les requêtes RegisterPublisher effectuées à l'aide d'un espace de nom de sujet WS-Notification qui fait référence à l'espace de sujets supprimé reçoivent un message d'erreur TopicNotSupportedFault.
  • Les requêtes Notify pour un sujet associé à l'espace de sujet supprimé n'envoient pas le message à l'espace de sujet (puisqu'il a été supprimé). L'application n'est pas informée puisque l'opération Notify ne renvoie aucun défaut (voir Une notification entrante (application vers courtier) échoue).
  • Les requêtes Subscribe utilisent un espace de nom de sujet WS-Notification qui fait référence à l'espace de sujets supprimé reçoivent un message d'erreur SubscribeCreateFailedFault.
  • Aucun autre message n'est distribué aux applications qui contiennent des abonnements existants sur l'espace de sujet supprimé. L'abonnement existant est supprimé et toute tentative d'appel d'opérations sur l'abonnement (par exemple getCreationTime) renvoie un message d'erreur ResourceUnknownFault.
  • La suppression et la nouvelle création d'un espace de sujet du bus d'intégration de services s'effectuent en deux étapes bien distinctes. Les abonnements existants sont supprimés en réponse à la première étape et, par conséquent, ils n'existent plus quand l'espace de sujet est de nouveau créé.
Suppression d'un mappage d'espace de nom de sujet permanent

La suppression du mappage d'espace de nom de sujet qui permettait d'établir un abonnement (actuellement actif) a le même effet que la suppression de l'espace de sujet du bus d'intégration de services sous-jacent comme défini précédemment, et les abonnements créés à l'aide de ce mappage d'espace de nom sont supprimés.

Les enregistrements de diffuseur de publications et les points d'extraction associés au mappage d'espace de nom de sujet supprimé sont également supprimés.

Modification d'un mappage d'espace de nom de sujet permanent

Les zones d'un mappage d'espace de nom de sujet permanent sont en lecture seulement ; par conséquent, pour "modifier" ces zones, vous devez supprimer le mappage d'espace de nom puis le créer de nouveau avec les nouvelles valeurs. Les conséquences de la suppression d'un mappage d'espace de nom de sujet permanent sont décrites dans la partie précédente.

Impossible de créer un service WS-Notification version 6.1 sans référentiel SDO configuré

Lorsque vous créez un service WS-Notification version 6.1, les documents WSDL sont sauvegardés dans le référentiel SDO. Le message d'exception suivant s'affiche si vous tentez de créer un service WS-Notification version 6.1 via la console d'administration ou à l'aide de scripts, avant de configurer correctement le référentiel SDO.
java.lang.Exception: com.ibm.ws.sib.webservices.admin.config.SIBConfigException: CWSWS5010E: Echec du 
stockage du WSDL situé à http://www.ibm.com/websphere/wsn/notification-broker en raison de 
l'exception suivante :
    com.ibm.ws.sib.webservices.exception.SIBWSUnloggedException: CWSWS1007E: L'exception suivante 
        s'est produite : com.ibm.ws.sdo.config.repository.impl.RepositoryRuntimeException: 
        javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0x0 No; exception 
        imbriquée : 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.
    [Exception initiale : javax.naming.NameNotFoundException: Contexte : 
        KADGINNode01Cell/nodes/KADGINNode01/servers/server1, nom : 
        jdbc/com.ibm.ws.sdo.config/SdoRepository: Premier composant dans le nom 
        com.ibm.ws.sdo.config/SdoRepository introuvable.
    [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: 
        IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]] vmcid: 0x0 minor code: 0 completed: No.
Pour obtenir des informations détaillées sur la procédure de configuration du référentiel SDO, voir Installation et configuration du référentiel SDO.

Une exception se produit lorsqu'un client JAX-WS qui n'a pas d'accès Internet tente de contacter un service WS-Notification.

L'application client résout généralemmennt les parties WSDL du service en suivant des liens Web. Si la machine où s'exécute le client n'a pas d'accès Internet, une exception similaire à celle indiquée ci-dessous se produit :
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

Configurez le client pour utiliser une copie locale du fichier WSDL à la place en suivant les instructions de la rubrique Configuration d'un client JAX-WS pour résoudre un document WSDL de service sans suivre des liaisons Web..


Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rjwsn_prob0
Nom du fichier : rjwsn_prob0.html