WebSphere Enterprise Service Bus, Version 6.2.0 Systèmes d'exploitation: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Identification et résolution des incidents liés à la migration entre différentes versions

Consultez cette page pour résoudre les incidents qui peuvent se produire lors de la migration à partir d'une version antérieure de WebSphere ESB.

Les sections suivantes décrivent les erreurs et les exceptions qui peuvent survenir dans une migration de version à version ; vous y trouverez également les étapes à suivre pour comprendre et résoudre ces problèmes.

Erreur d'installation des applications

Si vous sélectionnez l'option indiquant au processus de migration que les applications d'entreprise existantes dans la configuration de version 6.0.x ou 6.1.x doivent être installées dans la nouvelle configuration de version 6.2, il est possible que certains messages d'erreur soient émis durant la phase de migration des applications installées.

Les applications qui existent dans la configuration de version 6.0.x ou 6.1.x comportent parfois des informations de déploiement incorrectes. Généralement, il s'agit de documents XML incorrects n'ayant pas fait l'objet d'une validation suffisante lors des précédentes exécutions de WebSphere ESB. Le programme d'exécution comporte désormais un processus amélioré de validation de l'installation des applications, qui empêche l'installation de fichiers EAR syntaxiquement incorrects. Il en résulte un échec de la phase d'installation des applications pour la commande WBIPostUpgrade et l'émission d'un message "E:".

Si l'installation de l'application échoue ainsi lors de la migration, vous pouvez procéder de l'une des manières suivantes :
  • Résolvez les incidents liés aux applications de version 6.0.x ou 6.1.x, puis effectuez une nouvelle migration.
  • Procédez à la migration en ignorant ces erreurs.

    Dans ce cas, le processus de migration n'installe pas les applications ayant échoué, mais exécute toutes les autres étapes de migration.

    Vous pourrez résoudre ultérieurement les incidents affectant les applications, puis les installer manuellement dans la nouvelle configuration de version 6.2 à l'aide de la console d'administration ou d'un script d'installation.

Erreur du serveur d'applications

Après la migration d'un noeud géré vers version 6.2, il est possible que le démarrage du serveur d'applications échoue.

Lorsque vous tentez de démarrer le serveur d'applications, des erreurs similaires à celles de l'exemple suivant peuvent être consignées :
[5/11/06 15:41:23:190 CDT] 0000000a SystemErr  R  com.ibm.ws.exception.RuntimeError:
com.ibm.ws.exception.RuntimeError:  org.omg.CORBA.INTERNAL: 
   CREATE_LISTENER_FAILED_4
vmcid: 0x49421000  minor code: 56  completed: No
[5/11/06 15:41:23:196 CDT] 0000000a SystemErr  R  at  com.ibm.ws.runtime.WsServerImpl.bootServerContainer(WsServerImpl.java:198)
[5/11/06 15:41:23:196 CDT] 0000000a SystemErr  R  at  com.ibm.ws.runtime.WsServerImpl.start(WsServerImpl.java:139)
[5/11/06 15:41:23:196 CDT] 0000000a SystemErr  R  at  com.ibm.ws.runtime.WsServerImpl.main(WsServerImpl.java:460)
[5/11/06 15:41:23:196 CDT] 0000000a SystemErr  R  at  com.ibm.ws.runtime.WsServer.main(WsServer.java:59)
[5/11/06 15:41:23:196 CDT] 0000000a SystemErr  R  at  sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[5/11/06 15:41:23:196 CDT] 0000000a SystemErr  R  at  sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
[5/11/06 15:41:23:197 CDT] 0000000a SystemErr  R  at  sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Changez le numéro du port d'écoute utilisé par le serveur du noeud géré. Si le gestionnaire de déploiement utilise par exemple le port d'écoute 9101 pour ORB_LISTENER_ADDRESS, il convient que le serveur du noeud géré n'utilise pas le port d'écoute 9101 pour son instance ORB_LISTENER_ADDRESS. Pour résoudre le problème dans cet exemple, procédez comme suit :
  1. Dans la console d'administration, cliquez sur Serveurs d'applications > nom_serveur > Ports > ORB_LISTENER_ADDRESS.
  2. Changez le numéro de port ORB_LISTENER_ADDRESS en sélectionnant un port inutilisé.

Exceptions : connectivité de la base de données, chargement ou classe manquante

Ne jamais modifier de variable WebSphere Application Server configurée au cours de la création du profil.

Si vous modifiez ces valeurs de façon incorrecte dans un ancien profil, vous êtes susceptible de recevoir des exceptions de connectivité de base de données, chargement ou d'autres classes, telles que :

10/25/08 13:22:39:650 GMT+08:00] 0000002e J2CUtilityCla E J2CA0036E: An exception occurred while invoking method setDataSourceProperties on com.ibm.ws.rsadapter.spi.WSManagedConnectionFactoryImpl used by resource jdbc/com.ibm.ws.sib/ewps6101.Messaging-BPC.cwfpcCell01.Bus : com.ibm.ws.exception.WsException: DSRA0023E: The DataSource implementation class "com.ibm.db2.jcc.DB2XADataSource" could not be found.DB2,

Les pilotes Derby, et SQL Embedded JDBC sont regroupés dans l'installation du produit WebSphere ESB. Si vous devez mettre à jour ces pilotes vers une version supérieure, vous devez copier les pilotes dans le même emplacement que celui où ils existent dans l'installation du produit, comme suit :
  • Derby : %was.install.root%\derby\lib
  • DB2 : %was.install.root%/universalDriver_wbi/lib
  • SQL : %was.install.root%lib
Si vous avez besoin d'un nouveau fournisseur JDBC et d'une nouvelle source de données pour votre application,vous pouvez créer ces ressources en sélectionnant un jdbcclasspath valide et en définissant la variable de WebSphere Application Server en fonction. Par exemple, si vous avez besoin d'un pilote DB2 au niveau de la cellule qui n'existait pas dans une installation précédente, vous pouvez suivre la procédure ci-dessous.
  1. Depuis la console d'administration, naviguez jusqu'à : Ressources > JDBC > Fournisseurs JDBC > Fournisseur de pilote JDBC DB2 Universal (XA).
  2. Dans l'encadré Chemin de la classe, définissez les chemins suivants :
    • DB2UNIVERSAL_JDBC_DRIVER_PATH =%was.install.root%/universalDriver_wbi/lib
    • DB2UNIVERSAL_JDBC_DRIVER_NATIVEPATH=""
    Si vous avez besoin de vos propres pilotes, définissez le chemin suivant : DB2UNIVERSAL_JDBC_DRIVER_PATH=%myDriverLocation%

Erreur liée à une mémoire insuffisante

Si l'utilitaire de ligne de commande WBIPreUpgrade ou WBIPostUpgrade échoue en raison d'un manque de mémoire, vous pouvez augmenter la taille du tas (heap) à une valeur prenant en considération d'une part la taille et l'étendue de l'environnement en cours de migration, d'autre part la capacité mémoire de la machine.

Pour obtenir des instructions permettant d'augmenter la taille de segment, voir la procédure décrite dans la note technique suivante (Solution 4) : Handling certain Out of Memory conditions when migrating an earlier version of WebSphere Application Server to V6.0.2, V6.1, or 7.0 ((Traitement de certaines conditions de saturation de mémoire lors de la migration d'une version antérieure de WebSphere Application Server vers la version 6.0.2, 6.1 ou 7.0).

Erreur à la création de profils

Lors de l'utilisation de l'assistant de migration de version 6.2 pour créer un profil lors de la migration d'une configuration, les messages d'erreur suivants, relatifs à la création de profils, peuvent apparaître.

profileName: profileName ne peut pas être vide
profilePath: Espace disque insuffisant

Ces messages d'erreur s'affichent parfois lors de la saisie d'un nom de profil contenant un caractère non valide, tel qu'un espace. Réexécutez l'assistant de migration et vérifiez que le nom du profil ne contient aucun caractère non valide (espace, guillemets) ni d'autres caractères spéciaux.

Erreur de migration de profils

Lorsque vous utilisez l'assistant de migration pour migrer un profil de WebSphere ESB version 6.0.x ou 6.1.x vers version 6.2 sur un système avec un processeur Solaris x64, il se peut que la migration échoue lors de l'étape WBIPostUpgrade.

Il est possible que des messages similaires au suivant apparaissent dans le fichier racine_profil/logs/WASPostUpgrade.horodatage.log :
MIGR0327E: A failure occurred with stopNode.
MIGR0272E: The migration function cannot complete the command.

WebSphere ESB version 6.0.x ou 6.1.x utilise une machine virtuelle Java™ (JVM) en mode 32 bits. L'assistant de migration pour WebSphere ESB version 6.2 appelle le script WBIPostUpgrade.sh, qui tente d'exécuter la machine virtuelle Java pour version 6.0.x ou 6.1.x en mode 64 bits lorsque le serveur arrête le noeud version 6.0.x ou 6.1.x.

Effectuez les actions suivantes pour supprimer le profil incomplet et permettre à WebSphere ESB de faire migrer correctement le profil version 6.0.x ou 6.1.x :
  1. Sur une ligne de commande, accédez au répertoire racine_installation/bin.
    Par exemple, entrez la commande suivante :
    cd /opt/IBM/WebSphere/ESB/bin
  2. Localisez le script WBIPostUpgrade.sh dans le répertoire racine_installation/bin et effectuez-en une copie de sauvegarde.
  3. Ouvrez le fichier WBIPostUpgrade.sh ou WBIPostUpgrade.bat dans un éditeur de texte et effectuez les actions suivantes :
    1. Recherchez la ligne de code suivante :
      For UNIX operating systemFor Linux operating system
      "$binDir" /setupCmdLine.sh
      For Windows operating system
      call "%~dp0setupCmdLine.bat" %*
    2. Insérez la ligne de code suivante à la suite de celle que vous avez identifiée à l'étape précédente :
      JVM_EXTRA_CMD_ARGS=""
    3. Sauvegardez les modifications.
  4. Répétez les étapes 2 à 4 avec le fichier WASPostUpgrade.sh ou WASPostUpgrade.bat.
  5. Supprimez le profil version 6.2 incomplet créé lors du processus de migration. Utilisez la procédure suivante.
    1. Ouvrez une invite de commande et exécutez l'une des commandes suivantes selon votre système d'exploitation :
      • For i5/OS operating system Sur les plateformes i5/OS : manageprofiles -delete -profileName nom_profil
      • For Linux operating systemFor UNIX operating system Sur les plateformes Linux® et UNIX® : manageprofiles.sh -delete -profileName nom_profil
      • For Windows operating system Sur les plateformes Windows® : manageprofiles.bat -delete -profileName nom_profil

      La variable nom_profil représente le nom du profil à supprimer.

    2. Vérifiez que la suppression de profil a abouti en examinant le fichier journal suivant :
      • For i5/OS operating system Sur les plateformes i5/OS : racine_données_utilisateur/profileRegistry/logs/manageprofiles/nom_profil_delete.log
      • For Linux operating systemFor UNIX operating system Sous Linux et UNIX : racine_installation/logs/manageprofiles/nom_profil_delete.log
      • For Windows operating system Sur les plateformes Windows : racine_installation\logs\manageprofiles\nom_profil_delete.log
  6. Supprimez le répertoire racine_profil du profil version 6.2 supprimé à l'étape précédente.
  7. Exécutez à nouveau l'assistant de migration.

Erreur de synchronisation

En cas d'échec de la synchronisation après la migration d'un noeud géré vers version 6.2, il est possible que le serveur ne démarre pas.

Lors de la migration d'un noeud géré vers version 6.2, des messages similaires aux suivants peuvent être consignés :
ADMU0016I: Synchronizing configuration between node and cell.
ADMU0111E: Program exiting with error:
           com.ibm.websphere.management.exception.AdminException: ADMU0005E:
           Error synchronizing repositories
ADMU0211I: Error details may be seen in the file:
           /opt/WebSphere/62AppServer/profiles/AppSrv02/logs/syncNode.log
MIGR0350W: Synchronization with the deployment manager using the SOAP protocol 
 failed.
MIGR0307I: The restoration of the previous WebSphere Application Server 
 environment is complete.
MIGR0271W: Migration completed successfully, with one or more warnings.
Ces messages indique les situations suivantes :
  • Votre gestionnaire de déploiement est configuré au niveau version 6.2.
  • Le noeud géré que vous tentez de faire migrer se trouve au niveau de configuration version 6.2 dans le référentiel du gestionnaire de déploiement (y compris les applications).
  • Le noeud géré lui-même est relativement incomplet, car vous n'avez pas terminé l'opération syncNode.
Pour résoudre ce problème, exécutez les actions suivantes :
  1. Exécutez à nouveau la commande syncNode sur le noeud afin de le synchroniser avec le gestionnaire de déploiement.

    Reportez-vous à la rubrique Commande 'syncNode' .

  2. Exécutez la commande GenPluginCfg.

    Reportez-vous à la rubrique Commande 'GenPluginCfg' .


reference Rubrique de référence

Conditions d'utilisation | Commentaires en retour


Icône d'horodatage Dernière mise à jour: 07 juillet 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/tmig_vtv_troublesht.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
Ce centre d'information est mis en service par la technologie Eclipse (http://www.eclipse.org).