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.2 Moteur de collecte de données
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 fonction de copie de fichiers du moteur de collecte de données ne fonctionne pas sous HP 11i
1.2.3 Le moteur de collecte de données signale l'erreur "sh: sysdef: not found" sous Solaris
1.2.4 Me moteur de collecte de données exécuté avec une machine JVM Sun sous Linux entre dans une boucle infinie
1.2.5 L'extension d'agent ne fonctionne pas sur les systèmes iSeries
1.2.6 Une même machine ne peut pas contenir plusieurs instances du moteur de collecte de données
1.3 Analyseur de trace et de journaux
1.3.1 Impossible de définir un chemin de travail lors du profilage
1.3.2 Les agents et les processus sont perdus lors de la fermeture du monteur de profilage
1.3.3 La régénération des vues risque de ne pas fonctionner suivant l'option sélectionnée dans le moniteur de profilage
1.4 Probekit
1.4.1 *Le programme ProbeInstrumenter supprime tous les fichiers jar du répertoire META-INF
1.4.2 *Le programme ProbeInstrumenter génère une exception lors de l'instrumentation de certaines classes
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 une machine JVM Sun, 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 d'une 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.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 Le déploiement et l'exécution automatisés de tests sur des plateformes hétérogènes ne fonctionnent pas
1.7.1.3 Exécution à distance avec déploiement manuel
1.7.1.4 Accès au pool de données
1.7.2 Test d'URL Hyades
1.7.2.1 Les rapports sur le taux de réussite et le temps de réponse des URL ne sont pas visibles dans le navigateur de test
1.7.2.2 L'enregistreur de test d'URL affiche le message "IWAT3042E Arrêt de l'enregistrement en raison de l'exception : null"
1.7.2.3 Exécution de test d'URL comme tests JUnit
1.7.2.4 Exécution de l'exemple de test d'URL
1.7.2.5 Le fichier readme.html de l'exemple de test d'URL fait référence à tort à "Test de composant"
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 (Java Runtime Environment) version 1.4.1 d'IBM pour l'utilisation de Generic Log Adapter ou l'importation de fichiers journaux dans Hyades à l'aide d'un analyseur syntaxique de fichiers journaux basé sur des règles.
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 se produit sur toutes les plateformes, exceptées Z/OS et iSeries.
Pour résoudre cet incident, ajoutez l'argument VM Java -Dconsole.encoding=UTF8 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 vers le plan de travail Eclipse.
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.5 $
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.5 $
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, entrez : 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.Le moteur de collecte de données de Hyades utilise la commande sysdef pour obtenir la taille maximale d'une mémoire tampon partagée sur votre système. Si le moteur de collecte de données ne parvient pas à exécuter sysdef, il utilise la valeur dataChannelSize="30M" spécifiée dans le fichier <ServeurRA>/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 foundPour résoudre cet incident, ajoutez le répertoire /usr/sbin, qui contient sysdef, à la variable PATH.
<SERVER_MSG time="2004:6:3:17:42:49" severity="INFORMATION" text="Démarrage en cours du service"/>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 moteur de collecte de données. Par exemple, avant d'exécuter RAServer, lancez la commande suivante :
<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="AVERTISSEMENT" text="Arrêt du serveur"/>
<SERVER_MSG time="2004:6:3:17:42:49" severity="AVERTISSEMENT" text="Serveur interne fermé"/>
<SERVER_MSG time="2004:6:3:17:42:49" severity="AVERTISSEMENT" text="Serveur externe fermé"/>
<SERVER_MSG time="2004:6:3:17:42:49" severity="AVERTISSEMENT" text="Arrêt du serveur"/>
<SERVER_MSG time="2004:6:3:17:42:49" severity="AVERTISSEMENT" text="Serveur interne fermé"/>
<SERVER_MSG time="2004:6:3:17:42:49" severity="AVERTISSEMENT" text="Serveur externe fermé"/>
export
LD_LIBRARY_PATH=/opt/j2sdk1.4.2_04/jre/lib/i386/server:/opt/j2sdk1.4.2_04/jre/li
b/i386
Les extensions d'agent ne fonctionnent pas sur les systèmes iSeries.
Pour résoudre cet incident, avant de démarrer le moteur de collecte de données sur la machine iSeries, exécutez la commande suivante :
ADDLIBLE NOMLIBNOMLIB correspondant au nom de la bibliothèque qui contient le code des extensions d'agent. Cela permet au moteur de collecte de données de rechercher et charger la bibliothèque.
Vous ne pouvez installer qu'une instance du moteur de collecte de données 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 moteur de collecte de données de Hyades sous le nom Agent Controller.
Incident Bugzilla : 61754
Il n'existe actuellement aucun moyen de définir un chemin de travail arbitraire lors de
la configuration d'une application à profiler.
La zone Répertoire de travail de la page Arguments du type d'application Java
n'est pas traitée correctement par le programme de lancement et n'est pas envoyée du plan
de travail au moteur de collecte de données.
Pour les applications Java de type externe, il n'existe aucune zone permettant de
spécifier un chemin de travail.
Pour résoudre cet incident, procédez comme suit :
Incident Bugzilla : 51161
Si des données non sauvegardées telles que des agents ou des processus sont affichées
dans la vue Moniteur de profilage, elles sont perdues lorsque la vue est fermée. Il est recommandé de sauvegarder l'intégralité du contenu dans
le moniteur de profilage avant de fermer la vue.
Remarque : Si vous ouvrez une nouvelle perspective, puis passez à la perspective
Profilage et consignation, les données ne sont pas perdues.
Incident Bugzilla : 71567
Si l'option Lier à l'afficheur est désactivée dans la vue Moniteur de profilage, l'action
Régénérer les vues (dans la même barre d'outils) ne fonctionne que si l'option
actuellement sélectionnée dans la vue Moniteur de profilage correspond à la vue
actuellement ouverte.
Pour résoudre cet incident, utilisez l'une des méthodes suivantes :
Si le répertoire META-INF du fichier Jar contient des fichiers autres que le fichier MANIFEST.MF, effectuez la procédure suivante pour conserver ces fichiers dans le fichier Jar instrumenté :
jar xf votrefichier.jar META-INF
jar uf votrefichier.jar META-INF
Remarque : Cet incident a été résolu dans la version 6.0.0.1.
Incident Bugzilla :68435
Lors de l'instrumentation de certaines classes, le programme "ProbeInstrumenter" de
Probekit génère une exception avec le message d'erreur suivant :
Probe Kit Exception number 4 from location 3
Cette exception peut avoir pour origine des méthodes contenant des pseudo-codes inaccessibles après la dernière instruction accessible d'une méthode. Certains compilateurs Java génèrent ce type de code.
Il n'existe actuellement aucune solution à cet incident.
Remarque : Cet incident a été résolu dans la version 6.0.0.1.
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.
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.
Incident Bugzilla :56404
Lors du profilage sous Solaris à l'aide de Sun JDK 1.4.x, la machine JVM peut tomber en
panne. Cela 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 deux modes ou si l'option "Afficher les informations de niveau instance" est activée.
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.
Incident Bugzilla : 63969
Si IBM 1.4.2 JDK est utilisé, avec l'option de profile jvmpi Hyades "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.
Incidents Bugzilla : 65193 et 72180
En raison d'un bogue JDK, lors de l'exécution de Hyades 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é.
Non disponible
Le déploiement et l'exécution automatisés de tests sur des systèmes éloignés utilisant des plateformes hétérogènes (Windows sur Linux ou Unix et vice versa) ne fonctionnent pas. Vous trouverez des informations sur l'exécution d'un test à distance dans la rubrique Exécution à distance du présent document.
Incident Bugzilla :68910
Un test (URL, JUnit ou Manuel) courant consiste à installer le plan de travail
(Interface graphique d'Eclipse) sur une machine Windows et à effectuer l'exécution à
distance sur un système Linux ou Unix. Actuellement, le déploiement automatisé ne
fonctionne pas entre des plateformes différentes. Toutefois, vous pouvez quand même
exécuter des tests à distance.
Le fichier du test à exécuter doit être transféré (généralement à l'aide de la commande
FTP) du système sur lequel il a été créé vers le système à partir duquel il doit
être exécuté. Le collecteur de données ou RAC doit être configuré de sorte à tester les
ressources transférées.
Lorsque le pseudo-code d'un test est compilé, il est stocké dans le répertoire bin du projet Java dans lequel le test a été créé. Par exemple :
[ECLIPSE_HOME]/workspace/project1/bin/test/URLTest.class
Une méthode de génération du package du fichier ci-dessus pour une exécution sur un système éloigné consiste à créer un fichier Jar. Les commandes ci-après montrent comment cela peut être accompli.
"cd [ECLIPSE_HOME]/workspace/project1/bin"
"jar -cf test.jar test"
Le fichier test.jar peut alors être transféré dans la structure de répertoires du collecteur de données de la machine éloignée.
Vous devez ensuite éditer le fichier [RAC_HOME]/config/serviceconfig.xml pour qu'il fasse référence au fichier test.jar, comme indiqué ci-après.
<AgentControllerEnvironment configuration="default">
...
...
<Variable name="CLASSPATH" position="append" value="%RASERVER_HOME%/test/test.jar"/>
</AgentControllerEnvironment>
Lorsque le test est lancé à partir du plan de travail, le chemin d'accès aux classes du collecteur de données fait référence à l'emplacement du test et le test est exécuté.
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 Hyades 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();
}
Incident Bugzilla :68553
Les rapports sur le taux de réussite et le temps de
réponse des URL ne sont pas visibles dans le navigateur de test. Vous pouvez accéder à
ces rapports en ouvrant le projet sous lequel ils ont été créés dans la perspective
Ressource.
Incident Bugzilla :66199
Lorsqu'Eclipse est lancé avec l'argument "-Xj9", après plusieurs enregistrements la vue
Contrôle de l'enregistreur affiche le message "IWAT3042E Arrêt de l'enregistrement en
raison de l'exception : null". La solution consiste à fermer, puis rouvrir Eclipse.
Les tests d'URL Hyades 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.0.0/hlcore.jar
[ECLIPSE_HOME]/plugins/org.eclipse.hyades.logging.core_3.0.0/hlcbe101.jar
[ECLIPSE_HOME]/plugins/org.eclipse.emf.ecore_2.0.0/runtime/ecore.jar
[ECLIPSE_HOME]/plugins/org.eclipse.hyades.logging.java14_3.0.0/hl14.jar
[ECLIPSE_HOME]/plugins/org.eclipse.emf.common_2.0.0/runtime/common.jar
L'exemple de test d'URL n'est pas exécuté directement après sa création. Deux artefacts doivent être configurés pour qu'il puisse être exécuté. La variable CLASSPATH de l'artefact 1 doit faire référence à l'emplacement de l'espace de travail sur la machine :
[ECLIPSE_HOME]/eclipse/workspace/URL Test Sample/bin
La variable ROOTDIR de l'emplacement 1 doit faire référence au répertoire qui représente l'espace de travail
[ECLIPSE_HOME]/workspace
Le nom par défaut de l'exemple de test d'URL contient des espaces. Cela peut poser des difficultés dans certains systèmes d'exploitation. Le nom de l'exemple peut être modifié lors de la création de ce dernier.
Incident Bugzilla :68910
La page Web de l'exemple de test d'URL fait référence à la rubrique d'aide en ligne "Test de composant" qui n'existe pas. La page Web doit faire référence à la rubrique "Test" de l'aide en ligne.
Retour au fichier Readme principal