Conseils relatifs au traitement des incidents liés aux moteurs de messagerie

Cet ensemble de conseils spécifiques vous permet d'identifier et de résoudre les incidents liés aux moteurs de messagerie d'intégration de services.

Le démarrage du moteur de messagerie échoue car l'exécution n'est pas encore initialisée

Un moteur de messagerie ne parvient pas à démarrer et l'erreur suivante s'affiche dans la console d'administration WebSphere Application Server :

Impossible de démarrer le moteur de messagerie <nom> car aucun environnement d'exécution 
n'est initialisé pour lui. Tentez à nouveau l'opération dès qu'un environnement sera initialisé.  
Si le rechargement de configuration dynamique est activé pour ce bus, les serveurs doivent être redémarrés.

Avant de tenter de redémarrer le moteur de messagerie, vérifiez que vous avez redémarré le serveur. Pour que l'environnement d'exécution s'initialise correctement, vous devez redémarrer le serveur d'applications.

Pour déterminer si une erreur de démarrage empêche l'initialisation de l'environnement d'exécution du moteur de messagerie, recherchez les messages d'erreur dans le journal SystemOut.log sur le serveur hôte.
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.
[z/OS]

Le moteur de messagerie ne démarre pas avec un pilote DB2 Universal JDBC type 2

Lorsqu'il tente d'utiliser le pilote DB2 Universal JDBC type 2 pour stocker les données sur la plate-forme z/OS, le moteur de messagerie ne parvient pas à démarrer et des messages "Erreur d'attribution de stockage" similaires au message suivant peuvent apparaître dans le fichier WebSphere Application Server SystemOut.log :

BBOO0220E: [SB6NLA1:SB6NLA1.server1-SB6NLA1] CWSIP0002E: Une
erreur de messagerie interne s'est produite dans com.ibm.ws.sib.processor.im
pl.MessageProcessor, 1:1469:1.365, com.ibm.ws.sib.msgstore.Messa
geStoreRuntimeException: com.ibm.ws.sib.msgstore.PersistenceExce
ption: CWSIS1501E: La source de données a produit une exception
inattendue : com.ibm.db2.jcc.t2zos.y: [IBM/DB2][T2zos/2.5.48]T2zo
sPreparedStatement.readPrepareDescribeOutput_:processDescribeOut
put:1563:Erreur d'attribution de stockage dans com.ibm.ws.sib.msgstore.cac
he.links.AbstractItemLink.readDataFromPersistence(AbstractItemLi
nk.java:2487) dans
com.ibm.ws.sib.msgstore.cache.links.AbstractItemLink._restoreIte
m(AbstractItemLink.java:639)
Pour la plate-forme z/OS , il est conseillé d'utiliser un pilote DB2 Universal JDBC type 4. Si vous devez utiliser le pilote DB2 Universal JDBC type 2, effectuez les étapes suivantes :
  1. Utilisez la console d'administration pour naviguer vers Ressources -> JDBC -> Sources de données -> nom_source_données -> [Propriétés supplémentaires] Propriétés personnalisées
  2. Définissez la propriété personnalisée du pilote JDBC fullyMaterializeLobData sur false.

    La propriété personnalisée fullyMaterializeLobData détermine si les données LOB sont matérialisées en totalité dans le pilote JDBC lors de l'extraction d'une ligne ou si elles sont extraites en plusieurs parties. Le comportement réel varie selon si le serveur de base de données prend en charge ou non le flot de données progressif. Pour plus d'informations sur cette propriété, consultez votre documentation DB2. La valeur par défaut est true.

  3. Sauvegardez les modifications de la configuration principale.
  4. Redémarrez le serveur d'applications.

Le moteur de messagerie ne démarre pas en raison d'une erreur de pilote Informix JDBC Driver 3.00JC1

Lorsqu'il tente d'utiliser le pilote Informix JDBC Driver 3.00JC1 pour stocker les données, le moteur de messagerie ne parvient pas à démarrer et le message d'erreur suivant peut apparaître dans le fichier SystemOut.log de WebSphere Application Server :

00000022 SibMessage E [RetireBus:retire_web.000- RetireBus] CWSIS0002E: 
Une exception s'est produite lors du démarrage du moteur de messagerie. 
Exception : com.ibm.ws.sib.msgstore.PersistenceException : CWSIS1501E : 
La source de données a généré une exception imprévue : java.sql.BatchUpdateException:
Contrainte unique (informix.u114_62) violée.
00000022 SibMessage E [RetireBus:retire_web.000- RetireBus] CWSID0035E : 
Impossible de démarrer le moteur de messagerie retire_web.000-RetireBus ;
erreur signalée lors de com.ibm.ws.sib.msgstore.impl.MessageStoreImpl start() 
00000022 SibMessage E [RetireBus:retire_web.000- RetireBus] CWSID0027I : 
Impossible de démarrer le moteur de messagerie retire_web.000-RetireBus en raison d'une erreur grave.T] 00000022 SibMessage I [RetireBus:retire_web.000- RetireBus] CWSID0016I : 
Le moteur de messagerie retire_web.000-RetireBus est arrêté.  

Un incident connu (PTS 172471) s'est produit dans Informix JDBC Driver 3.00JC1. Pour éviter cet incident, installez la version 3.00JC2 d'Informix JDBC Driver.

Identification des incidents pour un magasin de données

Vous pouvez créer un cliché, sous forme réduite, des données du magasin de données d'un moteur de messagerie. La sortie est destinée au personnel de maintenance IBM. Pour plus d'informations sur comment exécuter la commande, adressez-vous à votre service d'assistance.
S'il existe un incident concernant les données du magasin de données, il peut être difficile d'effectuer un diagnostic à partir de la sortie de la trace. Toutefois, vous pouvez créer un cliché, au format XML, des données du magasin de données. Cela facilite le diagnostic car il s'agit d'une représentation lisible par l'utilisateur qui peut être convertie en d'autres formats si nécessaire. Vous pouvez créer un vidage du magasin de données en entrant la commande suivante dans l'outil wsadmin :
  • Langage Jython :
    AdminControl.invoke(AdminControl.queryNames("type=SIBMessagingEngine,name=messagingenginename,*"),
     "dump", "com.ibm.ws.sib.msgstore.*")
  • Avec Jacl :
    $AdminControl invoke [$AdminControl queryNames type=SIBMessagingEngine,
     name=nom_moteur_messagerie,*] 
     dump com.ibm.ws.sib.msgstore.*

Le cliché est créé sous forme de fichier XML dans le répertoire $WAS_HOME/logs/server1. Le fichier est nommé conformément au format suivant : nom_moteur_messagerieUUIDhorodatage.xml

Le format du fichier est illustré dans l'exemple suivant :
<MessageStore>
    <itemStreams>
        <ItemStreamLink id="0" state="Available">
            <class>com.ibm.ws.sib.msgstore.ItemStream</class>
            <priority>5</priority>
            <canExpireSilently></canExpireSilently>
            <storageStrategy>STORE_NEVER</storageStrategy>
            <expiryTime>0</expiryTime>
            <sequence>0</sequence>
            <tranID>null</tranID>
            <tickValue>0</tickValue>
            <items>
                <ItemLink id="2" state="Available" refCount="3" refCountDecreasing="false">
                    <class>com.ibm.ws.sib.msgstore.Item</class>
                    <priority>5</priority>
                    <canExpireSilently></canExpireSilently>
                    <storageStrategy>STORE_NEVER</storageStrategy>
                    <expiryTime>0</expiryTime>
                    <sequence>1</sequence>
                    <tranID>null</tranID>
                    <tickValue>0</tickValue>
                </ItemLink></items></ItemStreamLink></itemStreams></MessageStore>

Les moteurs de messagerie génèrent des messages de conflit de base de données

Lorsqu'un moteur de messagerie qui utilise un magasin de données pour l'emplacement de stockage des messages est lancé deux fois par erreur, un message de conflit de base de données est affiché :
CWSIS1546I : Le moteur de messagerie, ME_UUID={0}, INC_UUID={1}, a perdu un verrou existant ou n'a pas réussi à obtenir un verrou initial sur le magasin de données.
Pour résoudre le problème, procédez comme suit :
  • Vérifiez s'il existe des problèmes liés à la base de données, par exemple, la base de données n'est pas disponible.
  • Vérifiez si des incidents se sont produits sur le réseau. Par exemple, si le réseau est surchargé, il se peut que deux serveurs d'applications puissent se connecter à la base de données sans toutefois pouvoir se connecter l'un à l'autre, générant ainsi des problèmes de coordination de ressources.
  • Si vous disposez d'une configuration d'intégration de services offrant des options de haute disponibilité ou de partage de la charge de travail, assurez-vous que les ressources appropriées sont correctement configurées. Par exemple, vérifiez les moteurs de messagerie, les règles de groupe central associées à ces moteurs ainsi que les critères de correspondance qui associent chaque règle de groupe central à un moteur de messagerie. Voir Configuration de la haute disponibilité et partage de la charge de travail de l'intégration de services.
[AIX Solaris HP-UX Linux Windows][IBM i]

Exception d'ID utilisateur non pris en charge lors de la connexion à une base de données Apache Derby version 10.3 reliée au réseau

Lorsque vous testez la connexion à votre base de données Apache Derby version 10.3 reliée au réseau, l'exception suivante est générée :
java.lang.Exception: java.sql.SQLException: null userid not supported DSRA0010E: SQL State = null, Error
[IBM i][AIX Solaris HP-UX Linux Windows]Lorsque vous créez un magasin de données Apache Derby connecté à un réseau, vous obtenez par défaut un alias d'authentification vide.[IBM i][AIX Solaris HP-UX Linux Windows]Si vous utilisez Apache Derby en mode Network Attached avec DB2 Universal JDBC Driver (si vous utilisez "fournisseur JDBC pour Derby Network Server utilisant (DB2) Universal JDBC Driver"), vous devez spécifier un alias d'authentification. Cette exigence est décrite dans Paramètres minimum requis des sources de données pour Apache Derby.
Remarque : [AIX Solaris HP-UX Linux Windows][IBM i]Le besoin d'un alias d'authentification concerne uniquement le "fournisseur JDBC pour Derby Network Server utilisant (DB2) Universal JDBC Driver". Ce pilote est obsolète et remplacé par le "fournisseur JDBC pour Derby Network Server utilisant Derby Client", qui n'a pas besoin d'alias d'authentification.
Reportez-vous également à la rubrique Configuration d'une source de données JDBC pour un moteur de messagerie.

Causes possibles de l'exception XAResourceNotAvailableException et actions appropriées

Si la commande deleteNode est utilisée pour un noeud hébergeant des moteurs de messagerie, ces derniers sont supprimés. Lorsque des moteurs de messagerie sont créés à nouveau suite à la commande addNode, leur identificateur est différent et il n'est donc plus possible de se connecter aux anciens moteurs de messagerie lors de la récupération des transactions. Un message identifiant l'exception XAResourceNotAvailableException est généré dans le fichier SystemOut.log de chaque serveur qui héberge un moteur de messagerie.

Pour résoudre cet incident, vous devez suivre la procédure décrite dans Résolution de transactions en attente de validation.

L'exception XAResourceNotAvailableException peut être également générée lorsqu'un serveur d'un membre de bus de cluster bascule sur un autre serveur. Dans ce cas, aucune opération de l'utilisateur n'est requise pour récupérer et résoudre les transactions.

Incidents lors de la nouvelle création d'un bus d'intégration de services

Si vous supprimez un bus d'intégration de services, puis créez par la suite un bus portant le même nom, le moteur de messagerie ne démarre pas et des messages, tels que les messages suivants sont générés dans le fichier SystemOut.log :
[8/11/04 21:55:01:439 CDT] 0000000f SibMessage    I   
[LateBus:xyzsun15.server1-LateBus] isAlive: Le moteur de messagerie a détecté une erreur
de mode courante. 
Corrigez l'erreur (voir les journaux) et redémarrez le serveur.
[8/11/04 21:55:01:468 CDT] 0000000f SibMessage    I   
[LateBus:xyzsun15.server1-LateBus] isAlive: Le moteur de messagerie va être arrêté 
en raison d'une erreur de mode courante. 
Aucune reprise en ligne n'aura lieu.
[8/11/04 21:55:01:493 CDT] 0000000f SibMessage    I   
[LateBus:xyzsun15.server1-LateBus] Le moteur de messagerie xyzsun15.server1-LateBus ne
se trouve pas dans un état lui permettant d'être arrêté : Démarrage en cours
[8/11/04 21:55:01:513 CDT] 0000000f SibMessage    I   
[LateBus:xyzsun15.server1-LateBus] isAlive: Le moteur de messagerie va être arrêté 
en raison d'une erreur de mode courante. Corrigez l'erreur (voir les journaux) et redémarrez le serveur.
[8/11/04 21:57:01:431 CDT] 0000000e SibMessage    I   
[LateBus:xyzsun15.server1-LateBus] isAlive: Le moteur de messagerie a détecté une erreur
de mode courante. 
Corrigez l'erreur (voir les journaux) et redémarrez le serveur.

Le moteur de messagerie ne parvient pas à démarrer car le répertoire de la base de données du moteur de messagerie existe toujours une fois le bus supprimé et doit être supprimé manuellement. Pour supprimer la base de données Apache Derby d'un moteur de messagerie inexistant, vous devez supprimer le répertoire de la base de données situé dans racine_profil/databases/com.ibm.ws.sib, racine_profil étant le répertoire contenant les informations spécifiques au profil.

Vous devez arrêter WebSphere Application Server avant de supprimer les fichiers de la base de données.

Pour les autres bases de données, vous pouvez supprimer toutes les lignes des tables du magasin de données ou supprimer toutes les tables du magasin de données. Ces tables respectent le schéma configuré pour le magasin de données. Pour une liste de tables, voir Tables des magasins de données.

Pour plus d'informations, voir Cycle de vie d'un magasin de données.

Incidents lors de la communication avec des bus externes

Il est nécessaire de créer un bus externe et un lien de bus d'intégration de services pour permettre aux bus de communiquer. Le nom du bus externe du premier bus doit correspondre au nom du deuxième bus, qui devient un bus externe, et le nom du bus externe de ce deuxième bus doit être identique au nom du premier bus. Le lien de bus d'intégration de services doit avoir le même nom sur les deux bus.

Si votre configuration est incorrecte (par ex. les liens de bus d'intégration de services ne correspondent pas), le type de message d'erreur suivant peut apparaître :

SibMessage    E   [TechBus:TechCluster.000-TechBus] 
CWSIT0057E: The inter-bus connection BookstoreBus failed in the remote 
messaging engine on host aixp401.rchland.ibm.com with reason: 
CWSIT0067E: Inter-bus connection BookstoreBus in bus BookstoreBus 
is not available.

Incidents lors de la tentative de communication avec un bus externe renommé

Le panneau de la console d'administration permettant de configurer les propriétés d'un lien de bus d'intégration de services permet également de modifier le nom du bus externe désigné par le lien. Cependant, vous ne devez pas modifier le nom du bus externe une fois qu'il a été configuré. Si vous le modifiez, les moteurs de messagerie comportant déjà des informations d'état sur le lien ne pourront pas utiliser le lien jusqu'à ce que le nom du bus externe soit redéfini à sa valeur précédente.

Causes possible d'une exception JMSException avec une exception SILimitExceeded encapsulée

Lorsque le nombre de messages se trouvant dans la destination atteint sa limite maximale, toute tentative d'envoi de message à cette destination n'aboutit pas et une exception JMSException avec une exception SILimitExceeded encapsulée est générée. La destination échoue toujours avec cette exception jusqu'à ce que le nombre de messages détenus par la destination tombe en dessous du seuil.

Pour obtenir un nombre précis des messages disponibles, vous pouvez contrôler la statistique PMI du nombre de messages disponibles pour les destinations de file d'attente et d'espace de sujet. Si le nombre de messages disponibles augmente, pensez à équilibrer le système. Tant que la destination n'a pas réceptionné de messages disponibles, empêchez les expéditeurs d'envoyer des messages.

Consultez la liste suivante pour connaître les causes et les solutions possibles de cet incident :
  • Le seuil maximal de la destination est trop faible pour le nombre projeté de messages. La destination ne traite pas certains messages. La valeur par défaut du seuil maximal est 50000.
    Solution : Augmentez le seuil maximal pour la destination.
  • Les applications génèrent plus de messages que la destination peut en traiter.

    L'idéal est que le nombre de messages générés soit égal au nombre de messages utilisés pendant une période définie. Si le système n'est pas équilibré et que l'application génératrice envoie plus de messages que la destination peut en utiliser, l'application génératrice émet éventuellement une exception JMS.

    Solution : Equilibre entre le nombre de messages générés et le nombre de messages utilisés.
    Conseil : Le paramètre par défaut du pool d'unités d'exécution ORB (Object Request Broker) est de 100 unités d'exécution. Dans certaines applications, ce paramètre permet à 100 applications d'envoyer des messages à la même destination. Pensez à régler le pool d'unités d'exécution ORB de manière à avoir au maximum 10 unités d'exécution. Ce paramètre permet de réduire le nombre d'applications pouvant envoyer des messages, ce qui peut augmenter le débit général des messages.
  • Les applications traitent les messages de la destination pas assez rapidement.
    Solution : Il peut être nécessaire d'augmenter le nombre de messages utilisés par les applications client. Une destination traite plus de messages lorsque plusieurs destinataires effectuent une lecture à partir de cette destination.

    Pensez à cloner votre application sur plusieurs serveurs dans un environnement qui n'est pas en clusters. Par défaut, les applications sont clonées dans un environnement de serveur en clusters. Pour activer les abonnés dans un environnement qui n'est pas en clusters, définissez l'indicateur cloné dans le paramètre JNDI TopicConnectionFactory pour les abonnements durables.

    Restriction : Cette solution ne s'applique pas aux applications pour lesquelles un tri des messages est requis.
  • Les messages possèdent un attribut de qualité de service qui est mieux que le mode best effort pour les messages non persistants.
    Solution : Utilisez les messages dont l'attribut de qualité de service est meilleur effort non persistant. S'il existe trop de messages dans le système, la destination élimine les messages ayant l'attribut Meilleur effort non persistant.
    Restriction : Cette solution ne s'applique pas aux applications qui doivent recevoir tous les messages.

Corruption lors du redémarrage du système

Bien que cela soit rare, il est possible qu'un moteur de messagerie, une destination ou un lien soit corrompu(e) une fois le système redémarré. Lorsque cela se produit, un message s'affiche signalant l'incident. Si l'incident est lié au moteur de messagerie, ce dernier ne démarre pas. Si une destination ou un lien est corrompu(e), le moteur de messagerie correspondant démarre mais il n'est pas possible d'utiliser la destination ou le lien sur ce moteur de messagerie.

Si vous ne connaissez pas la cause de l'incident, contactez le technicien de maintenance IBM afin d'identifier la cause avant de résoudre le problème.

Si vous connaissez la cause de l'incident, par exemple, si vous savez qu'un incident est survenu dans votre base de données, résolvez-le en suivant la procédure ci-après.
  1. Utilisez la console d'administration pour vous assurer que les fichiers de configuration sont synchronisés dans le système, en naviguant vers Administration du système -> Noeuds et en cliquant sur Resynchronisation complète. L'exécution de cette opération peut prendre quelques minutes.
  2. Si l'incident persiste, effectuez une des tâches suivantes :

Extraction du statut des moteurs de messagerie dans la console d'administration

Pour pouvoir extraire le statut des moteurs de messagerie, vous devez être connecté à la console d'administration avec au minimum des droits de type moniteur. Si vous ne disposez pas de ces droits, le statut du moteur de messagerie est affiché comme étant "Indisponible" même si le moteur de messagerie n'a pas démarré.

Si vous n'êtes pas connecté avec les droits requis pour l'extraction du statut des moteurs de messagerie, un message d'erreur tel le message suivant est placé dans le fichier journal systemOut du serveur :
[4/20/05 10:49:57:083 CDT] 0000004b RoleBasedAuth A   SECJ0305I: Echec du contrôle d'autorisation basée sur le rôle pour l'opération admin-authz   SIBMessagingEngine:stateExtended. 
L'utilisateur NON AUTHENTIFIE (ID unique : non authentifié) n'a pas reçu l'un des rôles requis suivants :  administrateur, opérateur, configurateur, moniteur.
Où l'ID utilisateur affiché dans le message correspond à l'ID utilisateur utilisé pour la connexion à la console d'administration.

Permettre à une application de démarrer avant le moteur de messagerie requis

Si une application dépend de la disponibilité d'un moteur de messagerie, celui-ci doit démarrer avant l'exécution de l'application. Si vous souhaitez que le serveur d'applications lance une application automatiquement, développez l'application de façon à ce qu'elle vérifie que le moteur de messagerie requis a démarré et, le cas échéant, qu'elle attende le moteur de messagerie. Si cette technique est utilisée dans un bean de démarrage, la méthode de bean de démarrage doit exécuter la tâche (tester et attendre) dans une unité d'exécution distincte à l'aide des méthodes standard de gestionnaire de travaux, ceci afin que le démarrage du serveur d'applications ne soit pas différé.

Pour consulter un exemple de code portant sur le test et l'attente d'un moteur de messagerie, voir Applications dépendant de la disponibilité d'un moteur de messagerie.

[z/OS]

Des messages relatifs à la structure du canal s'affichent pendant le démarrage du serveur

Lorsque vous démarrez le serveur, les messages suivants d'information de structure de canal peuvent s'afficher dans le processus CRA (Control Region Adjunct). Ces messages n'indiquent pas qu'une erreur s'est produite et ils ne nécessitent aucune action.
  • Ce message est émis, car l'application qui contient le bean géré par message a démarré avant le moteur de messagerie.
    CWSIV0759W : Aucun moteur de messagerie approprié n'est actif sur le serveur local du bus {0} lors de l'activation d'un bean géré par message.

    Lorsque les moteurs de messagerie démarrent, un autre message d'information le confirme et le traitement des messages peut être effectué.

  • Ce message est émis à cause du démarrage asynchrone du canal de proxy TCP z/OS TCP.
    CHFW0030E: Erreur lors du démarrage de la chaîne {0} cause de l'exception {1}

    Lorsque les moteurs de messagerie démarrent, un autre message d'information le confirme et le traitement des messages peut être effectué.

    Ces messages apparaissent uniquement dans certains cas, par exemple, si vous changez les ports au cours de la migration.

  • Le message suivant peut s'afficher plusieurs fois dans le processus auxiliaire de la région de contrôle pendant le démarrage du serveur, même si la connexion aboutit lors des tentatives suivantes. Ce message est émis à cause du démarrage asynchrone du canal de proxy TCP z/OS et ne signifie pas qu'une erreur s'est produite.
    Trace: 2009/06/17 08:24:41.434 01 t=9C6B58 c=UNK key=P8 (00000011)
    Description: Log Java Message 
    Message: CHFW0030E: Error starting chain _InboundTCPProxyBridgeService 
    because of exception 
    com.ibm.wsspi.channel.framework.exception.RetryableChannelException: 
    An exception was thrown when attempting to start the TCPProxyChannel 
    com.ibm.ws.channel.framework.imp l.ChannelFrameworkImpl
    Ces messages peuvent être accompagnés d'une sortie FFDC (First Failure Data Capture) semblable à l'exemple suivant :
    Exception = com.ibm.wsspi.channel.framework.exception.RetryableChannelException
    Source = com.ibm.ws.channel.framework.impl.ChannelFrameworkImpl.startChainInternal
    probeid = 2577
    Stack Dump = com.ibm.wsspi.channel.framework.exception.RetryableChannelException: An exception was thrown when attempting 
    to start the TCPProxyChannel
    		at com.ibm.ws.tcpchannelproxy.jfap.impl.TCPProxyInboundChannel.start(TCPProxyInboundChannel.java:153)
    		at com.ibm.ws.channel.framework.impl.ChannelFrameworkImpl.startChannelInChain(ChannelFrameworkImpl.java:1410)
    		at com.ibm.ws.channel.framework.impl.ChannelFrameworkImpl.startChainInternal(ChannelFrameworkImpl.java:2863)
     		at com.ibm.ws.channel.framework.impl.WSChannelFrameworkImpl.startChainInternal(WSChannelFrameworkImpl.java:960)
    		at com.ibm.ws.channel.framework.impl.ChannelFrameworkImpl.startChainInternal(ChannelFrameworkImpl.java:2794)
     		at com.ibm.ws.channel.framework.impl.ChannelFrameworkImpl.startChain(ChannelFrameworkImpl.java:2779)
     		at com.ibm.ws.runtime.component.ChannelFrameworkServiceImpl.startChain(ChannelFrameworkServiceImpl.java:666)
     		at com.ibm.ws.sib.jfapchannel.framework.impl.ChannelFrameworkReference$TCPProxyBridgeServiceInboundChainStartupRunnable.run(ChannelFrameworkReference.java:1641)
    		at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1550)
    Caused by: com.ibm.ws.tcpchannelproxy.jfap.NotYetInitializedException: Server is not yet initialized
    		at com.ibm.ws.tcpchannelproxy.jfap.TCPProxyBridgeServicesImpl.startListening(TCPProxyBridgeServicesImpl.java:558)
    		at com.ibm.ws.tcpchannelproxy.jfap.impl.TCPProxyInboundChannel.start(TCPProxyInboundChannel.java:131)
    		... 8 more
    Enfin le message suivant doit s'afficher pour indiquer que le démarrage du canal de proxy TCP z/OS a abouti :
    Trace: 2009/06/17 08:24:51.449 01 t=9C6B58 c=UNK key=P8 (13007002)
       ThreadId: 00000003
       FunctionName: com.ibm.ws.channel.framework.impl.WSChannelFrameworkImpl
       SourceId: com.ibm.ws.channel.framework.impl.WSChannelFrameworkImpl
       Category: AUDIT
       ExtendedMessage: BBOO0222I: CHFW0019I: The Transport Channel Service has started 
    chain _InboundTCPProxyBridgeService.
[AIX Solaris HP-UX Linux Windows][IBM i][z/OS]

Le basculement du moteur de messagerie n'est pas pris en charge dans les clusters à versions mixtes comportant des serveurs Version 6

Un moteur de messagerie hébergé sur un serveur WebSphere Application Server Version 7.0 ou ultérieures ne peut pas basculer sur un moteur de messagerie hébergé sur un serveur WebSphere Application Server Version 6. Si vous avez un cluster de membres de bus consistant en un mélange de serveurs Version 6 et versions ultérieures, vous devez configurer la règle de haute disponibilité de manière à empêcher ce type de basculement.

Pour empêcher le basculement d'un moteur de messagerie Version 7.0 ou ultérieures sur un serveur Version 6, la règle de haute disponibilité de ce moteur doit être configurée de sorte que le cluster soit divisé en un ensemble de serveurs pour Version 6 et un autre ensemble de serveurs pour Version 7.0 ou ultérieures, et que le moteur de messagerie Version 7.0 ou ultérieures soit limité aux serveurs Version 7.0 ou ultérieures. Voir Configuration de la reprise en ligne (basculement) des moteurs de messagerie dans un cluster à versions mixtes.


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=rjk_prob0
Nom du fichier : rjk_prob0.html