Plateforme de tests et de performances Version 3.3.0 - Notes sur l'édition


1.0 Incidents et restrictions connus
1.1 Generic Log Adapter
1.1.1 Incidents lors de l'exécution des règles de Generic Log Adapter à l'aide de l'environnement JRE (Java Runtime Environment) Version 1.4.1 d'IBM
1.1.2 L'importation d'un fichier journal d'un système z/OS distant peut produire des données incomplètes
1.1.3 L'analyse syntaxique continue d'un fichier journal comportant un bas de page entraîne la perte d'enregistrements
1.1.4 Certains messages d'erreur apparaissent deux fois dans la vue Incidents de l'éditeur de configuration GLA
1.1.5 Generic Log Adapter ne prend pas en charge la création de règles pour l'analyse de formats d'horodatage multiples
1.1.6 Erreurs du programme de formatage dans la vue Incidents lorsque le nouveau fichier de l'adaptateur GLA est exécuté dans la perspective Generic Log Adapter
1.1.7 L'analyseur des règles de fichier journal des accès HTTP Server analyse certains enregistrements incorrectement
1.2 Contrôleur d'agent
1.2.1 Le texte de la console est altéré lors du profilage d'une application Java sur un système DBCS
1.2.2 La copie du fichier de Contrôleur d'agent ne fonctionne pas sous HP 11i
1.2.3 Le Contrôleur d'agent signale l'erreur "sh: sysdef: not found" sous Solaris
1.2.4 Le Contrôleur d'agent exécuté avec une machine JVM Sun sous Linux entre dans une boucle infinie
1.2.5 Les instances multiples du Contrôleur d'agent sur une seule machine ne sont pas autorisées
1.2.6 Les exceptions de fichiers non trouvés ne sont pas signalées par le moteur de transfert lorsque les fichiers situés sur le serveur distant sont introuvables
1.2.7 Exécution du Contrôleur d'agent en mode sécurisé sur iSeries
1.2.8 Les données ne sont pas collectées lorsque plusieurs agents sont contrôlés simultanément
1.2.9 Violation de segmentation lors de l'arrêt du Contrôleur d'agent
1.2.10 Erreur "Mémoire insuffisante" lors du profilage d'applications
1.2.11 Les données collectées par l'agent ne parviennent pas au client
1.2.12 Echec de la résiliation de l'agent exécuté dans un processus à agents multiples
1.2.13 Le contrôle de demande par homologue ne fonctionne pas sur les plateformes EBCDIC
1.3 Analyseur de trace et de journaux
1.3.1 Le contrôle continu de journal n'est pas pris en charge pour le système hôte local
1.3.2 Le fichier lisez-moi d'exemples de journalisation ne s'ouvre pas
1.3.3 L'importation de journal distant avec un filtre ne fonctionne pas lorsque le Contrôleur d'agent est démarré incorrectement
1.3.4 Le processus d'importation de journal distant reste en état actif lorsque le Contrôleur d'agent n'est pas démarré
1.3.5 L'importation de certains journaux d'accès HTTP Server peut entraîner une erreur "String index out of range" (index de chaîne hors limites)
1.3.6 Données illisibles dans certains événements lors de l'importation du journal d'événements système Microsoft Windows sur le système DBCS
1.3.7 Exception de pointeur nul lors de l'importation d'un journal vide
1.3.8 L'importation du journal d'événements d'application Windows génère des erreurs de formatage Common Base Event
1.3.9 L'importation de journal depuis un système HP-UX distant se bloque lorsque le nom de fichier journal défini n'est pas valide
1.4 Probekit
1.5 Outil de profilage
1.5.1 Incident lors de la récupération de place si IBM JDK 1.4.1 est utilisé
1.5.2 Avec Sun JVM, certains appels de méthode ne sont pas pris en compte par la fonction de trace
1.5.3 Le profilage sous Solaris à l'aide de Sun JDK 1.4.x peut entraîner une panne de la machine JVM
1.5.4 Panne potentielle lors de l'exécution en mode autonome avec STACK_INFORMATION=contiguous sous Solaris
1.5.5 Valeurs de délai d'expiration négatives pour les événements WAIT et WAITED
1.5.6 Vidages de moniteur incorrects avec IBM JDK 1.4.2
1.5.7 Comptes de méthode incorrects avec la mise en ligne JIT
1.5.8 Restrictions des statistiques de temps UC de niveau méthode sur AIX et Solaris
1.5.9 Echec du profilage vers un fichier de profil existant sous Linux
1.5.10 Importation de fichiers de profils générés par un profilage en arrière-plan
1.5.11 Vues de filtre en double à la suite d'une fermeture anormale du plan de travail
1.5.12 L'action de libération de mémoire peut échouer de manière silencieuse
1.5.13 Des options d'agent incorrectes sont envoyées lorsque Historique de l'exécution > Détails graphiques complets est sélectionné sans édition.
1.5.14 L'importation de fichier de profils avec filtrage au niveau du package affiche une vue vide
1.5.15 Le mode de profilage affiche plus de données que prévu
1.6 Console de statistiques
1.7 Test
1.7.1 Incidents de test communs
1.7.1.1 Les tests JUnit, manuels et d'URL ne fonctionnent pas sur iSeries
1.7.1.2 Accès au pool de données
1.7.2 Test d'URL
1.7.2.1 Exécution de tests d'URL comme tests JUnit
1.7.2.2 Exécution de l'exemple de test d'URL
 

1.0 Incidents et restrictions connus

1.1 Generic Log Adapter

1.1.1 Incidents lors de l'exécution des règles de Generic Log Adapter à l'aide de l'environnement JRE (Java Runtime Environment) version 1.4.1 d'IBM

Le programme IBM JDK 1.4.1 livré en 2003 est à l'origine d'incidents dans l'analyseur syntaxique des journaux d'accès Apache basé sur des règles.

Service Release (SR2) ou une version ultérieure est requis lors de l'exécution de l'environnement JRE Version 1.4.1 d'IBM pour l'utilisation de Generic Log Adapter ou l'importation de fichiers journaux à l'aide d'un analyseur syntaxique de fichiers journaux basé sur des règles.

1.1.2 L'importation d'un fichier journal d'un système z/OS distant peut produire des données incomplètes

Incident Bugzilla : 80730

L'importation d'un fichier journal d'un système z/OS distant à l'aide de l'Analyseur de trace et de journaux peut donner lieu à l'affichage de données incomplètes dans la vue Journal. Il se peut que l'opération d'importation s'arrête prématurément et que tous les enregistrements du journal n'apparaissent pas dans la vue Journal. Cet incident se produit si l'une des versions de JDK IBM suivantes est installée sur le système z/OS :

Cet incident est corrigé dans le JDK IBM 1.4.2 avec la modification provisoire logicielle UK00802.  Effectuez une mise à niveau du JDK vers cette version ou une version ultérieure.   Si vous ne pouvez pas mettre à niveau la version de JDK, modifiez la configuration du Contrôleur d'agent sur le système z/OS en procédant comme suit :

  1. Editez le fichier plugins/org.eclipse.hyades.logging.parsers/config/pluginconfig.xml situé dans le répertoire d'installation du Contrôleur d'agent.
  2. Ajoutez un paramètre à l'élément d'application RemoteLogParserLoader après le paramètre java.version. Par exemple :
    <Parameter position="prepend" value="-Djava.version=1.4"/>
    <Parameter position="prepend" value="-Djava.compiler=NONE"/>
    <Parameter position="append" value="&quot;config_path=%GLA_CONFIG_PATH%&quot;"/>
  3. Redémarrez le Contrôleur d'agent.
  4. Importez de nouveau le fichier journal.

1.1.3 L'analyse syntaxique continue d'un fichier journal comportant un bas de page entraîne la perte d'enregistrements

Incident Bugzilla : 97974

L'analyse syntaxique continue d'un fichier journal contenant une section de bas de page entraîne parfois la perte d'enregistrements dans le résultat. En particulier, lorsque de nouveaux enregistrements sont ajoutés à un fichier journal, le premier de ces enregistrements n'est pas analysé et n'est pas inclus dans la sortie analysée. Cet indicent se produit lorsque l'instance de contexte est configurée avec continuousOperation="true" dans le fichier de configuration d'adaptateur alors que le fichier contient une section de bas de page. Pour éviter cet incident, analysez le fichier journal une fois en configurant l'instance de contexte avec continuousOperation="false".

1.1.4 Certains messages d'erreur apparaissent en double dans la vue Incidents de l'éditeur de Configuration GLA

Incident Bugzilla : 101184

Certains messages d'erreur apparaissent plusieurs fois dans la vue Incidents de l'éditeur de configuration GLA. Les messages existants ne sont pas toujours effacés de la vue Incidents avant l'exécution du fichier de configuration d'adaptateur à l'aide du bouton Ré-exécuter l'adaptateur.... La modification et l'enregistrement du fichier effacent la vue Incidents et affichent toutes les erreurs de validation de configuration d'adaptateur.

1.1.5 Generic Log Adapter ne prend pas en charge la création de règles pour l'analyse de formats d'horodatage multiples

Generic Log Adapter ne prend pas en charge les fichiers journaux d'analyse syntaxique dont les formats d'horodatage sont liés aux environnements locaux avec un seul fichier de configuration d'adaptateur basée sur des règles. Si une application génère des fichiers journaux contenant des horodatages dont les formats dépendent de l'environnement local, ces journaux ne peuvent pas être analysés avec un seul adaptateur basé sur des règles. Par exemple, si le format de date est MM/jj/aa dans les fichiers journaux générés sur les systèmes en_US, aa/MM/jj sur les systèmes ja_JP et jj.MM.aa sur les systèmes de_DE, un fichier de configuration d'adaptateur distinct est requis pour l'analyse syntaxique de chaque fichier journal, chacun comportant une règle d'analyse utilisant le format d'horodatage correct pour l'environnement local.

1.1.6 Erreurs du programme de formatage dans la vue Incidents lorsque le nouveau fichier de l'adaptateur GLA est exécuté dans la perspective Generic Log Adapter

La vue Incidents de la perspective Generic Log Adapter renvoie l'erreur suivante en cas de tentative d'exécution d'un nouveau fichier d'adaptateur GLA à l'aide du bouton Ré-exécuter l'adaptateur..." :

IWAT0438E La classe Formatter CBE (Common Base Event) N76D20B0042411D98000E0362B33D6F0 ne peut pas créer de propriété CommmonBaseEvent car la propriété requise sourceComponentId est manquante.

Ce message indique que le composant de formatage de GLA n'a pas pu créer de Common Base Event car la propriété sourceComponentId, requise par Common Base Event, est manquante. Pour éviter cet incident, ajoutez des règles d'analyse syntaxique au fichier d'adaptateur pour les attributs sourceComponentId. Notez que la propriété de situation est également requise par Common Base Event. Pour éviter des erreurs similaires, ajoutez des règles d'analyse à l'adaptateur pour la propriété de situation. Seul le GLA crée des CommonBaseEvents contenant toutes les propriétés requises.

1.1.7 L'analyseur des règles de fichier journal des accès HTTP Server analyse certains enregistrements incorrectement

Incident Bugzilla: 101545

L'analyseur des règles de fichier journal des accès HTTP Server n'analyse pas correctement les enregistrements suivants :

9.26.5.6 - - [09/Feb/2005:17:07:53 -0500] "VERSION" 501 -
9.26.5.6 - - [09/Feb/2005:17:14:52 -0500] "GET_CONFIG\r" 501 -
9.26.5.6 - - [09/Feb/2005:17:15:00 -0500] "< NSP/0.2 >" 400 299
9.26.5.6 - - [09/Feb/2005:17:22:40 -0500] "\x16\x03\x01" 501 -

La gravité n'est pas analysée correctement pour les deux premiers et le dernier enregistrements. Certaines autres données d'enregistrement ne figurent pas correctement dans les éléments de données étendus.

1.2 Contrôleur d'agent

1.2.1 Le texte de la console est altéré lors du profilage d'une application Java sur un système DBCS

Lors du profilage d'une application Java éloignée dans Eclipse sur un système DBCS (Par exemple, un système en chinois traditionnel, en chinois simplifié, en japonais ou en coréen), le texte de la sortie de la console est altéré. Cet incident peut se produire sur toute plateforme.

Pour le résoudre, ajoutez l'argument VM Java -Dconsole.encoding=<native encoding> lors du lancement de l'application Java éloignée. Le codage se déroule alors correctement lors du transfert de la sortie de la console de l'extrémité éloignée au plan de travail Eclipse. Pour connaître le <codage natif> sous Windows, exécutez chcp à l'invite de commande. Par exemple, si vous obtenez le résultat 950, la valeur de <native encoding> est MS950. L'argument VM Java est alors -Dconsole.encoding=MS950. Pour obtenir la liste des codages valides, voir paragraphe "Supported Encodings" de la section "Internationalization" dans la documentation Java de Sun.

1.2.2 La copie de fichiers du Contrôleur d'agent ne fonctionne pas sous HP 11i

La fonction de copie de fichiers ne fonctionne pas car le serveur de fichiers ne démarre pas. Cela vient du fait que la bibliothèque JVM libjvm.sl n'est pas chargée lors de l'exécution, ce qui empêche l'exécution du serveur de fichiers.

Pour résoudre cet incident, vous devez installer la version PHSS_30049 ou une version ultérieure du correctif de l'outil linker. La version de l'outil linker dans le correctif 30049 se présente comme suit :

/bin/ld:
        $Revision: 1.2 $
        HP aC++ B3910B X.03.37.01 Classic Iostream Library
        HP aC++ B3910B X.03.37.01 Language Support Library
        ld_msgs.cat: $Revision: 1.2 $
        92453-07 linker command s800.sgs ld PA64 B.11.38 REL 031217

Pour vérifier le numéro de version, entrez : what /bin/ld

Pour répertorier les correctifs installés : swlist -l fileset

Recherchez les occurrences de "ld" à l'aide de la commande Grep pour obtenir le numéro de version du correctif cumulatif des outils ld et linker.

1.2.3 Le Contrôleur d'agent signale l'erreur "sh: sysdef: not found" sous Solaris

Le Contrôleur d'agent utilise la commande sysdef pour obtenir la taille maximale d'une mémoire tampon partagée sur votre système. Si le Contrôleur d'agent ne parvient pas à exécuter sysdef, il utilise la valeur dataChannelSize="30M" définie dans le fichier <RAServer>/plugins/org.eclipse.hyades.datacollection/pluginconfig.xml. L'erreur suivante est signalée sur la console à partir de laquelle la commande RAServer.exe a été lancée :

sh: sysdef: not found
Pour résoudre cet incident, ajoutez le répertoire /usr/sbin, qui contient sysdef, à la variable PATH.

1.2.4 Le Contrôleur d'agent exécuté avec une machine JVM Sun sous Linux entre dans une boucle infinie

Lors de l'exécution du Contrôleur d'agent sur une machine Linux avec une machine JVM Sun 1.4.2_04, le moteur entre dans une boucle infinie. Les messages suivants sont consignés dans le fichier servicelog.log et les trois dernières lignes de ce fichier sont répétées continuellement jusqu'à ce qu'une commande kill soit exécutée pour arrêter le processus RAServer :
<SERVER_MSG time="2004:6:3:17:42:49" severity="INFORMATION" text="Démarrage en cours du service"/>
<SERVER_MSG time="2004:6:3:17:42:49"
severity="INFORMATION" 
            text="Le plug-in a été chargé : org.eclipse.hyades.datacollection"/>
<SERVER_MSG time="2004:6:3:17:42:49"
severity="INFORMATION" 
            text="Le plug-in a été chargé : org.eclipse.hyades.logging.parsers"/>
<SERVER_MSG time="2004:6:3:17:42:49"
severity="INFORMATION" 
            text="Le plug-in a été chargé : org.eclipse.hyades.test"/>
<SERVER_MSG time="2004:6:3:17:42:49"
severity="INFORMATION" 
            text="Valeur par défaut affectée à la configuration active"/>
<SERVER_MSG time="2004:6:3:17:42:49"
severity="INFORMATION" 
            text="Configuration chargée : valeur par défaut"/>
<SERVER_MSG time="2004:6:3:17:42:49"
severity="INFORMATION" 
            text="Service démarré"/>  
<SERVER_MSG time="2004:6:3:17:42:49" severity="WARNING" text="Arrêt du serveur"/>
<SERVER_MSG time="2004:6:3:17:42:49" severity="WARNING" text="Serveur interne fermé"/>
<SERVER_MSG time="2004:6:3:17:42:49" severity="WARNING" text="Serveur externe fermé"/>
<SERVER_MSG time="2004:6:3:17:42:49" severity="WARNING" text="Arrêt du serveur"/>
<SERVER_MSG time="2004:6:3:17:42:49" severity="WARNING" text="Serveur interne fermé"/>
<SERVER_MSG time="2004:6:3:17:42:49" severity="AVERTISSEMENT" text="Serveur externe
fermé"/>
Pour résoudre cet incident, définissez la variable LD_LIBRARY_PATH de sorte qu'elle fasse référence à tous les fichiers .so avant de démarrer le Contrôleur d'agent. Par exemple, avant d'exécuter RAServer, lancez la commande suivante :
export 
LD_LIBRARY_PATH=/opt/j2sdk1.4.2_04/jre/lib/i386/server:/opt/j2sdk1.4.2_04/jre/li
b/i386

1.2.5 Les instances multiples du Contrôleur d'agent sur une seule machine ne sont pas autorisées

Vous ne pouvez installer qu'une seule instance du Contrôleur d'agent sur une même machine. Cela signifie que si vous avez installé le moteur ou une version étendue du moteur avec un autre produit, vous devez désinstaller cette instance pour qu'une nouvelle instance fonctionne correctement. Par exemple, certains produits IBM WebSphere Studio ou IBM Rational ou le produit Autonomic Computing Toolkit from developerWorks, incluent des installations facultatives du Contrôleur d'agent sous le nom Agent Controller.

1.2.6 Les exceptions de fichiers non trouvés ne sont pas signalées par le moteur de transfert lorsque les fichiers situés sur le serveur distant sont introuvables

Le protocole de transfert de fichier ne signale pas d'exception FileNotFoundException lorsque vous tentez une opération GET sur un fichier non existant à partir d'un serveur de fichiers distant. Au lieu de cela, il signale le transfert réussi d'un fichier de taille 0. Si un fichier de taille 0 est renvoyé après une opération GET, cela est dû au fait que le fichier n'existe pas sur le serveur distant ou qu'il existe et que sa taille est de 0. Actuellement, le protocole de transfert ne fait pas la différence entre ces deux possibilités.

1.2.7 Exécution du Contrôleur d'agent en mode sécurisé sur iSeries

L'exécution du Contrôleur d'agent en mode sécurisé sur iSeries requiert des droits d'accès spéciaux aux comptes. Le compte utilisateur utilisé pour démarrer le travail "RASTART" du Contrôleur d'agent doit avoir les droits d'accès spéciaux "*SECADM, *ALLOBJ". Il se peut que vous deviez ajouter ces droits d'accès en mettant à jour le profil utilisateur à l'aide de la commande "WRKUSRPRF".

1.2.8 Les données ne sont pas collectées lorsque plusieurs agents sont contrôlés simultanément

Il arrive que lors du contrôle simultané d'au moins deux agents associés à un seul processus, aucune donnée n'est collectée pour l'un des agents. Le canal de données de l'un des agents ne s'initialise pas correctement, ce qui fait qu'aucune donnée ne peut être renvoyée au client à partir de cet agent.

Pour résoudre cet incident, contrôlez un seul agent à la fois par processus.

1.2.9 Violation de segmentation lors de l'arrêt du Contrôleur d'agent

Incident Bugzilla : 99788

Une violation de segmentation est signalée lors de la fermeture du Contrôleur d'agent. Cela a pour unique effet l'interruption de l'affichage. Aucune action n'est requise. Cette violation de segmentation a été signalée sur Red Hat Enterprise Linux 3.0, mise à jour 4.

1.2.10 Erreur "Mémoire insuffisante" lors du profilage d'applications

Incident Bugzilla : 57786

Une erreur "Mémoire insuffisante" risque d'être générée par la machine JVM si les arguments JVM -Xmxnnn et -XrunpiAgent sont définis au démarrage de l'application alors que l'application est reliée et contrôlée avec la perspective Profilage et journalisation de TPTP. Les paramètres de l'attribut dataChannelSize pour l'Agent de profilage Java dans la configuration du Contrôleur d'agent peuvent avoir une incidence sur la quantité de mémoire disponible pour la machine JVM et entraîner une erreur de "Mémoire insuffisante". Pour résoudre cet incident, réduisez la valeur -Xmx et/ou la valeur dataChannelSize pour l'Agent de profilage Java.

1.2.11 Les données collectées par l'agent ne parviennent pas au client

Incident Bugzilla : 73668

Il arrive que lorsqu'un agent collecte les données, celles-ci ne sont pas envoyées au client contrôlant cet agent. Le message CommonBaseEvent suivant dans le fichier Agent Controller servicelog.log indique la cause de l'incident :

msg="Shared memory allocation failure: -518"

La mémoire tampon partagée utilisée comme canal pour l'envoi de données de l'agent au Contrôleur d'agent ne peut pas être allouée. Les noms de mémoires tampon partagées sont réutilisés lors du redémarrage du Contrôleur d'agent. Il peut arriver que les mémoires tampon partagées ne soient pas complètement effacées par le système après une utilisation préalable. Les tentatives d'allocation de mémoire tampon dont le nom n'a pas été effacé au préalable échouent systématiquement. Pour résoudre ce problème, procédez de nouveau à l'opération de contrôle pour utiliser un nom de mémoire tampon partagée différent.

1.2.12 Echec de la résiliation d'agent exécuté dans un processus à agents multiples

Incident Bugzilla : 100870

Lorsque vous tentez de résilier l'exécution d'un agent dans un processus comportant plusieurs agents, la résiliation aboutit mais l'état du processus reste non résilié. Les tentatives multiples de résiliation de l'agent sont également ne fonctionnent pas dans ce cas.

Pour résoudre cet incident, résiliez le processus de l'agent au niveau du processus et non au niveau de l'agent.

1.2.13 Le contrôle de demande par homologue ne fonctionne pas sur les plateformes EBCDIC

Le contrôle de demande par homologue ne fonctionne pas sur les plateformes EBCDIC. Il n'existe actuellement aucune solution à cet incident pour TPTP 3.3. Cette restriction a été supprimée dans TPTP 4.0.

1.3 Analyseur de trace et de journaux

1.3.1 Le contrôle continu de journal n'est pas pris en charge pour le système hôte local

L'analyseur de trace et de journaux ne prend pas en charge le contrôle continu des fichiers journaux par le biais du système hôte local. Il est toutefois possible de contrôler continuellement les fichiers journaux locaux par le biais de l'interface de bouclage (127.0.0.1) et ainsi de simuler une importation distante avec un fichier journal local. Dans ce cas, l'agent de journalisation peut être résilié à tout moment afin d'éviter une panne de l'interface utilisateur.

Pour importer ou contrôler continuellement par bouclage, le Contrôleur d'agent doit être démarré (cela n'est pas nécessaire pour l'importation à partir du système hôte local).

1.3.2 Le fichier lisez-moi d'exemples de journalisation ne s'ouvre pas

Lorsque vous créez un exemple de projet de journalisation (Fichier > Nouveau > Exemple), un fichier lisez-moi doit s'ouvrir dans le navigateur de votre système. Toutefois, si les préférences d'association de fichier du plan de travail n'ont pas été définies correctement, le fichier risque de ne pas s'ouvrir.

Pour résoudre cet incident, accédez la page des préférences d'association de fichiers en sélectionnant Fenêtre > Préférences, puis Plan de travail> Associations de fichiers. Dans la liste des types de fichiers, sélectionnez .html. Dans la liste Editeurs associés, cliquez sur Ajouter. Cliquez sur Programmes externes, puis sélectionnez votre navigateur par défaut. Cliquez sur OK. Cliquez sur OK pour appliquer la nouvelle préférence.

1.3.3 L'importation de journal distant avec un filtre ne fonctionne pas lorsque le Contrôleur d'agent est démarré incorrectement

Incident Bugzilla 95615

Une demande d'importation de fichier journal à partir d'un système non Windows avec application de filtre entraîne l'affichage du message suivant si le Contrôleur d'agent est démarré incorrectement :

"Une erreur s'est produite lors de la tentative d'importation du fichier journal  /home/user/app.log.
Motif : [Ljava.lang.StackTraceElement;@538c718"

L'exception suivante est générée en conséquence de cette erreur et est consignée dans le fichier .log. Si cette exception se trouve dans le fichier .log, cela indique également que le Contrôleur d'agent est démarré incorrectement :

org.eclipse.hyades.internal.execution.core.file.ServerNotAvailableException: 
     java.net.ConnectException: Connexion refusée : connect

Assurez-vous que les répertoires du JRE contenant des bibliothèques exécutables telles que libjvm.so sont ajoutées à la variable d'environnement PATH de la bibliothèque appropriée pour le système avant de démarrer le Contrôleur d'agent.  Pour plus d'informations, voir fichier getting_started.html situé dans le répertoire d'installation du Contrôleur d'agent.

1.3.4 Le processus d'importation de journal distant reste en état activé lorsque le Contrôleur d'agent n'est pas démarré

Incident Bugzilla 100084

Lors de la tentative d'importation d'un journal distant alors qu'un Contrôleur d'agent n'est pas exécuté sur le système distant, le message d'erreur "Echec de la connexion..." apparaît mais le processus d'importation répertorié dans le volet Journaux du Navigateur de journaux apparaît toujours en état activé alors que le processus est terminé. Pour résoudre cet incident, démarrez le Contrôleur d'agent sur le système distant et essayez de nouveau d'importer le journal avec la même configuration cible. L'état correct du processus est à présent affiché.

1.3.5 Le processus d'importation de journal distant reste indiqué en état actif lorsque le Contrôleur d'agent n'est pas démarré

Incident Bugzilla 100979

L'importation de certains journaux d'accès HTTP Server avec l'analyseur syntaxique statique risque de s'arrêter avant que tous les enregistrements soient analysés et un message similaire au suivant peut s'afficher :

IWAT0030E Une erreur s'est produite lors de l'exécution de l'analyseur de journal distant
"org.eclipse.hyades.logging.adapter.config.StaticParserWrapper": IWAT0412E
Des erreurs se sont produites lors de l'analyse syntaxique du fichier journal /home/userId/logs/access.log.
IWAT0357E Exception lors de l'analyse syntaxique du fichier /home/userId/logs/access.log :
org.eclipse.hyades.logging.parsers.LogParserException: IWAT0054E Erreur lors de l'analyse syntaxique
du journal des accès.
IWAT0306E Erreur lors de l'analyse du numéro de ligne 1535 :

9.26.5.6 - - [09/Feb/2005:17:07:53 -0500] "VERSION" 501 -
String index out of range: -2.

L'analyseur syntaxique statique de journaux d'accès HTTP Server ne peut pas analyser les enregistrements de journal qui n'incluent pas
de nom de fichier. Exemple de ce type d'enregistrement :

9.26.5.6 - - [09/Feb/2005:17:07:53 -0500] "VERSION" 501 -

Pour résoudre cet incident, utilisez l'analyseur syntaxique basé sur des règles pour importer le fichier journal.

1.3.6 Données illisibles dans certains événements lors de l'importation du journal d'événements système Microsoft Windows sur le système DBCS

Incident Bugzilla 95077

L'importation du journal d'événements système Microsoft Windows à partir d'un système utilisant un jeu de caractères codés sur deux octets peut entraîner la perte ou l'illisibilité de valeurs msg pour certains événements Common Base Event affichés dans la vue Journal.

1.3.7 Exception de pointeur nul lors de l'importation d'un journal vide

Incident Bugzilla 100743

Lorsqu'un journal vide est importé ou lorsqu'un filtre d'importation est utilisé pour filtrer tous les événements à enregistrer, la vue Journal apparaît vide et une exception NullPointerException (dans XMLLoader.endElement) risque d'être générée. Vérifiez le fichier journal ou essayez un filtre différent permettant le chargement de certains événements.

1.3.8 L'importation du journal d'événements d'application Windows génère des erreurs de formatage Common Base Event

Incident Bugzilla 101718

Lors de l'importation du journal d'événements d'application Microsoft Windows, il se peut que les messages suivants apparaissent :

IWAT0027E Erreur lors de l'importation des fichiers journaux indiqués.
IWAT0412E Des erreurs se sont produites lors de l'analyse syntaxique du fichier journal null.
IWAT0438E La classe Formatter CBE (Common Base Event) N6B1EE3005B511D880008CD5D1F4FA98 ne peut pas
créer de propriété CommmonBaseEvent car la propriété requise creationTime est manquante.

L'analyseur syntaxique de journal ne parvient pas à analyser certains enregistrements correctement. Toutefois, la plupart des enregistrements sont importés et affichés dans la vue Journal.

1.3.9 L'importation de journal d'un système HP-UX distant se bloque lorsqu'un fichier journal non valide est défini

Incident Bugzilla 101491

Si un nom de fichier journal non valide est défini lors de l'importation d'un journal depuis un système HP- UX distant, l'opération d'importation peut sembler interminable. La barre d'état des tâches affiche "Importation du fichier journal...", l'indicateur de déroulement continue à défiler et aucun message d'erreur n'apparaît. Dans cet état, le travail d'importation de fichier journal ne peut pas être annulé. Pour mettre fin au travail, arrêtez le plan de travail Eclipse. Pour résoudre cet incident, vérifiez que le nom du fichier journal défini est correct.

1.4 Probekit

Non disponible

1.5 Outil de profilage

1.5.1 Incident lors de la récupération de place si IBM JDK 1.4.1 est utilisé

Incident Bugzilla : 56182

Si l'application de l'utilisateur utilise une quantité d'espace de segment de mémoire extrêmement importante et que vous sélectionnez Collecter les références d'objets ou Lancer la récupération de place, la machine JVM peut éventuellement tomber en panne avec le message d'erreur suivant :

 **Out of memory, aborting**

*** panic: JVMCI023: Cannot allocate memory to collect heap dump in jvmpi_heap_dump

abnormal program termination

Vous pouvez essayer de remédier à cet incident en recommençant l'exécution sans le paramètre -Xmx, si vous l'utilisez actuellement.

1.5.2 Avec Sun JDK, certains appels de méthode ne sont pas pris en compte par la fonction de trace

Incident Bugzilla : 69051

Lors de l'utilisation de Sun JDK sous Windows, certains appels de méthode de programmes Java ne font pas l'objet d'une trace par JVMPI.

Il n'existe pas de solution connue.

1.5.3 Le profilage sous Solaris à l'aide de Sun JDK 1.4.x ou sur HP à l'aide du JDK 1.4.x HP peut entraîner une panne de la machine JVM

Incident Bugzilla :56404
Le profilage sous Solaris à l'aide de Sun JDK 1.4.x ou sur HP à l'aide du JDK 1.4.x HP peut entraîner une panne de la machine JVM.

Cet incident est dû à un bogue de la machine JVM Sun. Pour résoudre cet incident, n'utilisez qu'un jeu de profilage parmi les jeux suivants :

Cet incident survient si vous utilisez une combinaison de ces jeux de profilage ou si l'option "Afficher les informations de niveau instance" est activée. Vous pouvez effectuer une mise à niveau vers la compilation Sun JDK 1.4.2_08-b03, dans laquelle l'incident a été résolu.

Le bogue dans le JDK HP a été corrigé dans la version JDK 1.4.2_04. La seule solution sous HP consiste à effectuer une mise à niveau vers cette version de JDK ou une version ultérieure.

1.5.4 Panne potentielle lors d'une exécution en mode autonome avec STACK_INFORMATION=contiguous sous Solaris

Incident Bugzilla : 50090
Lors d'un profilage sous Solaris, des incidents liés au profilage autonome peuvent survenir. Cet incident ne se produit que si STACK_INFORMATION=contiguous (ou boundaryAndContiguous) et que TRACE_MODE=full. Il peut entraîner une panne de votre machine JVM.

Pour résoudre cet incident avec STACK_INFORMATION=contiguous, utilisez TRACE_MODE=noObjectCorrelation. Cet incident ne se produit pas si STACK_INFORMATION=none ou STACK_INFORMATION=normal.

1.5.5 Valeurs de délai d'expiration négatives pour les événements WAIT et WAITED

Incident Bugzilla : 63969

Si IBM 1.4.2 JDK est utilisé, avec l'option de profil jvmpi 'MONITOR_MODE=all' (en mode autonome), des attributs de délai d'expiration négatifs peuvent apparaître sur les éléments monitorWait et monitorWaited dans leur trace. Ces délais sont généralement extrêmement longs et sont exprimés en entiers positifs sur 64 bits. Ce bogue vient d'un bogue JDK.

Le bogue dans le JDK a été corrigé dans la version IBM JDK 1.4.2 SR1a. Une des solutions consiste à effectuer une mise à niveau vers ce niveau de JDK ou une version ultérieure.

1.5.6 Vidages de moniteur incorrects avec IBM JDK 1.4.2

Incidents Bugzilla : 65193 et 72180

En raison d'un bogue JDK, lors de l'exécution de la plateforme de tests et de performances en mode autonome, avec l'option de profil jvmpi 'MONITOR_MODE=all', vous risquez d'obtenir des vidages de moniteur incorrects. En particulier, pour le bogue 65193, cela se produit si l'argument VM "-Xj9" est utilisé.

1.5.7 Calcul de méthode incorrect avec la mise en ligne JIT

Incident Bugzilla 70660 (Incident clos car ne sera pas résolu)

Si vous pensez que les comptes de méthode affichés dans les outils d'analyse sont trop faibles, désactivez la mise en ligne JIT si vous l'utilisez. Ce problème se produit uniquement lorsque IBM Java 2 Runtime Environment Version 1.4.2 est utilisé et lorsque le JIT est actif.

Le seul moyen de résoudre cet incident est de désactiver la mise en ligne. Pour ce faire, modifiez la variable d'environnement suivante :

JITC_COMPILEOPT=NINLINING

1.5.8 Restrictions de statistiques de temps UC au niveau méthode sur AIX et Solaris

Dans TPTP 3.0 et 4.0, il est possible de collecter les statistiques de temps UC au niveau de la méthode. Vous pouvez afficher ces statistiques dans une colonne supplémentaire de la vue des statistiques de méthodes ou dans le tableau d'appels de méthode. Les restrictions de plateforme pour cette fonction sont les suivantes :

La création de rapports statistiques relatifs au temps UC de niveau méthode n'est pas prise en charge sur AIX 4.3.

Sous Aix Version 5.1, ces statistiques requièrent l'exportation de la variable d'environnement "AIXTHREAD_ENRUSG=ON".

La fonction de statistiques de temps UC au niveau méthode n'est pas prise en charge sous Solaris actuellement.

1.5.9 Echec du profilage vers un fichier de profil existant sous Linux

Incident Bugzilla : 95803

Les tentatives de profilage vers un fichier de profil existant échouent lorsqu'elles sont effectuées sur les plateformes Linux. Un séparateur de chemin incorrect est utilisé dans le code, ce qui génère une exception FileNotFoundException.

Pour résoudre cet incident, effectuez un profilage vers un nouveau fichier et non vers un fichier de profil existant.

1.5.10 Importation de fichiers de profils générés par un profilage en arrière-plan

Les fichiers de profils générés à partir d'un profilage en mode arrière-plan ne peuvent pas être importés correctement dans le plan de travail Eclipse car il leur manque l'élément <TRACE> du niveau supérieur.

La solution consiste à éditer manuellement le fichier de profils pour y ajouter la chaîne <TRACE> au début et la chaîne </TRACE> à la fin du fichier avant de l'importer dans le plan de travail Eclipse.

1.5.11 Vues de filtre affichées en double à la suite d'une fermeture anormale du plan de travail

Incident Bugzilla : 97894

Si le plan de travail tombe en panne ou se ferme de façon anormale, il se peut que les filtres de trace et de journal ne soient pas enregistrés correctement, ce qui entraîne la création d'un nouveau filtre lors du relancement du plan de travail. Des filtres en double apparaissent par conséquent dans la vue de la liste de filtres.

Pour retirer un filtre en double, supprimez le filtre à l'aide de l'assistant de gestion de filtres, accessible à partir du menu déroulant de la vue.

1.5.12 L'action de libération de mémoire peut échouer de manière silencieuse

L'action de libération de mémoire risque d'échouer de manière silencieuse. Dans ce cas, vous devrez peut-être fermer et rouvrir la perspective Profilage et consignation.

1.5.13 Des options d'agent incorrectes sont définies lorsque Historique de l'éxécution > Détails graphiques complets est sélectionné sans édition.

Incident Bugzilla : 99492

Lorsque le jeu de profilage "Historique de l'exécution - Détails graphiques complets" est sélectionné sous l'onglet Profilage dans l'assistant de configuration de lancement de profil sans en modifier le contenu, la quantité de données de profilage collectées est plus importante que nécessaire. Des données de profilage supplémentaires telles que les données d'attribution d'objet sont collectées.

Pour résoudre cet incident, cliquez sur Editer après avoir sélectionné le jeu de profilage "Historique de l'exécution - Détails graphiques complets", puis avancez dans l'assistant en cliquant sur Suivant pour passer d'une page à l'autre. Une fois que vous êtes à la fin de l'assistant, cliquez sur Terminer pour mettre à jour les paramètres du jeu de profilage.

1.5.14 L'importation de fichier de profils avec filtrage au niveau du package affiche une vue vide

Incident Bugzilla : 100334

Lorsque le fichier de profils est généré avec le type de profilage Analyse de la mémoire sélectionné, les événements ne sont pas enregistrés dans un ordre chronologique dans le fichier de profils. Cela entraîne des échecs tels que la perte de packages lorsque le fichier de profils est ensuite importé avec un filtrage au niveau du package.

Pour résoudre cet incident, importez le fichier de profils sans aucun filtrage au niveau du package et filtrez les données dans les vues statistiques une fois l'importation terminée.

1.5.15 Le mode de profilage affiche davantage de données que prévu

Si le profilage d'une application est effectué avec les types de profilage suivants : Analyse de base de la mémoire sans information au niveau de l'instance et Analyse de la durée d'exécution avec graphique du flux d'exécution et sans informations de niveau instance, les informations de niveau instance s'affichent dans la vue Statistiques d'exécution lorsque le bouton de barre d'outil Informations de niveau instance est sélectionné.

1.6 Console de statistiques

Non disponible

1.7 Test

1.7.1 Incidents de test communs

1.7.1.1 Les tests JUnit, manuels et d'URL ne fonctionnent pas sur iSeries

Incident Bugzilla :68899

1.7.1.2 Accès au pool de données

Incident Bugzilla :68911
Il manque une étape dans la documentation qui décrit la manière d'accéder à un pool de données à partir d'un test et cette documentation contient un exemple de code qui ne fonctionne pas complètement.

Les fichiers Jar ci-après doivent être ajoutés au chemin de compilation Java. ([ECLIPSE_HOME] correspond au répertoire d'installation d'Eclipse.

	[ECLIPSE_HOME]/plugins/org.eclipse.hyades.models.common_3.0.0/common_model.jar
	[ECLIPSE_HOME]/plugins/org.eclipse.hyades.test.datapool_3.0.0/datapool_api.jar
	[ECLIPSE_HOME]/plugins/org.eclipse.emf.ecore_2.0.0/runtime/ecore.jar
	[ECLIPSE_HOME]/plugins/org.eclipse.emf.common_2.0.0/runtime/common.jar
	

Le fragment de code ci-après montre comment accéder à un pool de données et en extraire correctement les informations.  

	IDatapoolFactory dpFactory = new Common_DatapoolFactoryImpl();
	IDatapool datapool = dpFactory.load(new File("d:\\hyades3.0\\workspace\\testproj\\dpoo1.datapool"), false);
	IDatapoolIterator iter = dpFactory.open(datapool, "org.eclipse.hyades.datapool.DatapoolIteratorSequentialPrivate");
	iter.dpInitialize(datapool, -1);

	while (!iter.dpDone())
	{
		String firstName = iter.dpCurrent().getCell("First Name").getStringValue();
		//
votre code ici
		iter.dpNext();
	}
	

1.7.2 Test d'URL

1.7.2.1 Exécution de tests d'URL comme tests JUnit

Les tests d'URL peuvent être exécutés comme tests JUnit. Pour cela, vous devez ajouter les entrées suivantes au chemin de compilation Java du projet contenant le test d'URL :

      [ECLIPSE_HOME]/plugins/org.eclipse.hyades.logging.core_3.3.0/hlcore.jar
      [ECLIPSE_HOME]/plugins/org.eclipse.hyades.logging.core_3.3.0/hlcbe101.jar
      [ECLIPSE_HOME]/plugins/org.eclipse.emf.ecore_2.0.2/runtime/ecore.jar
      [ECLIPSE_HOME]/plugins/org.eclipse.hyades.logging.java14_3.3.0/hl14.jar
      [ECLIPSE_HOME]/plugins/org.eclipse.emf.common_2.0.1/runtime/common.jar
	

1.7.2.2 Exécution de l'exemple de test d'URL

Les fichiers de classes et java ont été retirés de l'exemple de test d'URL afin d'éviter des incidents de compilation.   L'exemple n'est pas destiné à être exécuté.
 

Retour au fichier Readme principal