Important : Vous devez d'abord examiner l'environnement cible pour vous assurer qu'il a été testé, ou testez-le vous-même. La plupart des problèmes de l'agent Java sont liés au système d'exploitation ou à une machine virtuelle Java, plutôt qu'à une application. Veillez à suivre les instructions indiquées dans cette documentation. Si vous avez besoin d'informations complémentaires, cette rubrique aborde les problèmes les plus courants.
La plupart des problèmes graves impliquant l'agent Java pour DevTest surviennet lors du démarrage (par exemple, l'agent est introuvable, ou le processus tombe en panne ou se bloque). En règle générale, une fois ces problèmes réglés, les conditions sont correctes. A partir de là, il s'agit d'améliorer la configuration ou d'écrire des extensions.
Remarques :
Erreur lors du démarrage : Error occurred during initialization of VM. Could not find agent library in absolute path... (Une erreur s'est produite lors de l'initialisation de machine virtuelle. Bibliothèque de l'agent introuvable dans le chemin d'accès absolu..)
Vérifiez que la bibliothèque est disponible à l'emplacement et utilise la même architecture que Java (32 bits et 64 bits).
Vérifiez également qu'aucune dépendance ne manque dans la bibliothèque. Par exemple, utilisez depends.exe sur Win32, otool -L sur Mac OS X, ou ldd -d sur Linux et UNIX. Si des bibliothèques sont manquantes, vérifiez que la variable LD_LIBRARY_PATH est définie de sorte à inclure les répertoires dans lesquelles elles résident. Les conteneurs peuvent remplacer LD_LIBRARY_PATH dans leur script de démarrage. Le fait de définir la variable dans un shell plutôt que dans le script ou dans un outil d'administration spécifique au conteneur ne garantit pas qu'elle soit correctement définie.
Si ldd n'est pas correctement renvoyé, l'agent ne sera pas correctement exécuté. Par conséquent, la vérification du ldd est la première action à effectuer. Si une version de l'agent pour le système d'exploitation est introuvable, envisagez d'utiliser l'agent Java pur.
L'agent sort immédiatement, ou peu de temps après le démarrage du processus.
Si le message LISA AGENT: VM terminated (Agent pour LISA : machine virtuelle terminée) s'affiche, il est probable que le processus se soit terminé normalement. Plusieurs conteneurs disposent de processus de lanceur, il est donc normal qu'ils sortent rapidement.
Si ce message ne s'affiche pas ou qu'un vidage sur incident se produit (après le retour correct de ldd ), un bogue de l'agent peut être justifié. Informez le service de support et tentez d'utiliser l'agent Java pur. Si une panne ou un vidage se produit encore, il peut s'agir d'un bogue de la machine virtuelle Java. Cela se produit avec IBM JVM 1.5 sur certains systèmes d'exploitation, dû à une tentative d'instrumentation de threads. Dans ce cas, essayez de fournir l'argument de machine virtuelle Java de ligne de commande -Dlisa.debug=true.
L'agent sort avec le message GetEnv on jvmdi returned -3 (JNI_EVERSION) (GetEnv sur jvmdi renvoyé -3 (JNI_EVERSION)).
Essayez de spécifier l'option de ligne de commande -Xsov pour indiquer à la machine virtuelle Java d'utiliser ses bibliothèques activées par débogage. Si cela ne fonctionne pas (par exemple, un message d'erreur d'option non valide s'affiche), ce système d'exploitation n'est pas pris en charge.
L'agent sort avec le message "UTF ERROR" [../../../src/solaris/instrument/EncodingSupport_md.c":66] : ...".
Le message peut varier selon la version exacte du système d'exploitation et/ou de la machine virtuelle Java. En général, le message comprend l'un des éléments suivants : UTF ERROR ["../../../src/solaris/instrument/EncodingSupport_md.c":66]: Failed to complete iconv_open() setup (Impossible de terminer l'installation de iconv_open()).
Ce problème est dû à un bogue de certaines machines virtuelles Java Solaris qui se produit lorsque certains packs linguistiques ne sont pas installés. Pour corriger ce problème, installez le pack linguistique en-US en exécutant l'installation de pkg SUNWlang-enUS, puis de export LANG=en_US.UTF-8. De même, vous pouvez essayer d'utiliser l'agent natif.
L'agent se bloque ou renvoie de nombreuses exceptions lors du démarrage (LinkageErrors, CircularityErrors, etc.).
L'instrumentation du code d'octet Java à l'aide de Java peut entraîner une légère altération de l'ordre de chargement de précédentes classes (par exemple, java.*) et se terminer par un interblocage ou des erreurs de vérification de code d'octet.
Toutes les occurrences connues de ces problèmes ont été éliminées pour toutes les combinaisons de machines virtuelles Java et de systèmes d'exploitation. Toutefois, il est possible qu'une combinaison non testée se produise. Informez le service de support de ce problème. S'il s'agit d'un blocage, incluez un fil de discussion à votre problème transmis au service de support. Créez un fil de discussion en appuyant sur Ctrl+Pause sous Windows, CTRL+\ ou kill -3 <pid> sous UNIX/Linux. Vous pouvez également essayer l'agent Java, car l'ordre de chargement des classes est légèrement différent. Si une classe ou un package semble impliqué à chaque blocage de thread, essayez de lui ajouter une directive exclude dans le fichier rules.xml.
L'agent renvoie l'exception java.lang.VerifyErrors ou l'échange à chaud n'a aucun effet.
La prise en charge de l'échange à chaud de certaines versions de machines virtuelles Java ultérieures à 1.4 contient des bogues (instrumentation des classes après leur chargement).
Dans ce cas, désactivez l'échange à chaud en désactivant la propriété Enable hot instrumentation (Activer l'instrumentation à chaud).
Vous pouvez configurer cette propriété à partir de la fenêtre Agents du portail DevTest. La propriété s'affiche dans l'onglet Settings (Paramètres).
Vous devez déterminer à l'avance les classes et/ou les méthodes que vous voulez intercepter ou virtualiser, ainsi qu'ajouter les règles pour ces classes ou méthodes dans le fichier rules.xml, puis relancer le serveur. Ce processus est plus fastidieux que sur un serveur dynamique, mais il s'agit de la seule solution connue à ce problème.
Parfois, l'exception java.lang.VerifyError n'est pas visible dans les journaux, mais l'agent se comporte comme si la classe désignée n'était pas instrumentée ou renvoie des résultats aléatoires et peut même s'arrêter brutalement.
L'agent démarre, mais les consoles ou l'intermédiaire ne peuvent pas le détecter.
Généralement, cela est dû un problème lié à un pare-feu ou au port entre l'agent et l'intermédiaire.
La partie supérieure du journal de l'agent peut inclure l'avertissement suivant : Can't connect to broker at tcp://ip:port (Impossible de se connecter à l'intermédiaire sur tcp://ip:port). Vérifiez que l'adresse IP et le port que l'agent utilise sont corrects. Puis, vérifiez que l'intermédiaire écoute sur le port spécifié dans l'adresse IP spécifiée. netstat -ano | grep port doit afficher un port en écoute dans l'adresse IP, ou 0.0.0.0. Enfin, recherchez les problèmes liés au pare-feu en exécutant telnet ip port à partir de l'ordinateur de l'agent pour veiller à ce que l'intermédiaire puisse être détecté. Si c'est le cas, l'état de l'intermédiaire est susceptible d'être incorrect. Vérifiez le registre et les journaux de l'intermédiaire (et redémarrez-le si nécessaire).
L'agent entraîne l'expiration de certaines opérations.
Le comportement de certaines machines virtuelles Java (notamment les machines virtuelles Java IBM) est inadéquat après l'instrumentation de certaines de leurs classes de mise en réseau. En conséquence, les appels de mise en réseau peuvent échouer ou expirer sans raison apparente.
Pour éviter l'instrumentation de ces classes, tentez de fournir l'argument de machine virtuelle Java de ligne de commande -Dlisa.debug=true.
Si le problème n'est pas résolu, modifiez le fichier rules.xml pour exclure les packages de mise en réseau suivants :
<exclude class="java.net.**"/> <exclude class="java.nio.**"/> <exclude class="sun.nio.**"/>
java.lang.NoClassDefFoundError on com/itko/lisa/remote/transactions/TransactionDispatcher.class
Vérifiez que LisaAgent.jar est disponible, dispose de droits de lecture et qu'il n'est pas endommagé. Pour cela, la méthode la plus simple consiste à exécuter java -jar LisaAgent.jar -v.
Vérifiez également si l'application utilise OSGi. Si c'est le cas (comme pour JBoss 7), ajoutez com.itko aux packages système ou d'amorçage. La méthode d'ajout de com.itko dépend du conteneur, ce qui complique la fourniture d'instructions spécifiques. Toutefois, il s'agit généralement d'un fichier de configuration contenant une propriété qui spécifie une liste de packages ou un argument de machine virtuelle Java similaire.
Les exceptions liées la sécurité sont levées lorsque l'agent est activé.
Il est possible que les exceptions SecurityExceptions ou PermissionExceptions soient levées par l'application uniquement lorsque l'agent est activé avec la sécurité activée. Ce paramètre est désormais le paramètre par défaut.
La raison et la solution sont expliquées dans la section Sécurité de l'agent Java.
Utilisation de ressources anormale (UC, mémoire, descripteurs de fichier...)
Si l'utilisation de l'UC est anormalement élevée ou indique des pics réguliers, prenez note de la période des pics, car cela permettra de déterminer le ou les threads défectueux. Essayez également de désactiver CAI et le VSE.
Si vous obtenez des erreurs OutOfMemory, surveillez l'utilisation de segment de mémoire Java. Si elle dépasse la limite -Xmx, augmentez cette limite. Toutefois, évitez d'augmenter la limite si elle est déjà élevée et excessive par rapport à l'utilisation d'application normale sans l'agent. Dans ce cas, générez une image mémoire du segment de mémoire. Vous pouvez utiliser l'utilitaire WAS HeapDump pour WebSphere ou l'outil Eclipse MAT gratuit pour les versions antérieures. Si l'utilisation de la mémoire est inférieure à la limite de -Xmx au moment où l'erreur s'est produite, il s'agit probablement d'une fuite dans le code natif. Dans ce cas, informez le service de support.
Si vous obtenez des exceptions IOExceptions sans raison (par exemple, un nombre excessif de descripteurs de fichier), notamment sur UNIX ou Linux, vérifiez la valeur ulimit dans la zone (ulimit -n -H et ulimit -n -S). Si cette valeur est faible, demandez à l'administrateur de la zone de l'augmenter (une valeur inférieure à 4096 est considérée faible pour des applications J2EE modernes). N'oubliez pas de redémarrer ensuite.
L'agent tente de conserver le nombre de descripteurs de fichier sous cette limite en déclenchant un nettoyage de la mémoire lorsque la limite est proche. Si l'agent ne peut pas lire la limite lors du démarrage, il utilise une valeur par défaut de 1024. L'utilisation de cette valeur par défaut peut entraîner un nettoyage de la mémoire excessif et des pics d'UC semi-aléatoires et fréquents. Cette situation est décrite par les messages suivants dans les journaux :
Max (or preferred) handles limit approaching - triggering GC... (Limite de descripteurs maximum (ou préférée) proche - déclenchement du nettoyage de la mémoire...)
Dans ce cas, augmentez la valeur de la propriété Maximum number of handles (Nombre maximum descripteurs).
Vous pouvez configurer cette propriété à partir de la fenêtre Agents du portail DevTest. La propriété s'affiche dans l'onglet Settings (Paramètres).
Je peux voir que l'agent a démarré, mais les données de CAI sont manquantes ou incomplètes.
Le processus du cycle de vie de données comprend les étapes suivantes :
Les données manquantes ou incomplètes peuvent être le résultat d'un problème de l'une de ces étapes.
Consultez le journal de l'agent et recherchez des exceptions de capture. Consultez les journaux de l'intermédiaire et de la console et recherchez des exceptions de transfert ou de persistance.
Si aucune exception n'est présente, mais que les données manquantes sont toujours introuvables, activez le débogage ou la journalisation de développement dans les agents. Si aucune instruction similaire à Sent partial transaction (Transaction partielle envoyée) n'y figure, CAI est probablement désactivé.
Si aucune de ces étapes ne fournit de résultats concluants, contactez le service de support.
J'ai activé l'enregistrement ou la lecture de Java pour le VSE, mais le VSE ne reçoit aucune demande de l'agent.
En premier lieu, vérifiez que l'agent est en mode d'enregistrement de lecture de VSE Ouvrez le journal d'agent et recherchez "Starting VSE record/playback...
Puis, recherchez des exceptions dans les journaux de l'agent et du VSE. S'ils sont corrects, il est possible que la classe que vous considériez virtualisée ne le soit pas. Recherchez une instruction similaire à Virtualized com.xxx... dans le journal d'agent. Si elle n'y figure pas, il est possible que l'application n'ait pas encore chargé la classe. Il est également possible que des versions antérieures à Java 1.4 ne prennent pas en charge l'échange à chaud. Le VSE Java utilise l'échange à chaud par défaut. Dans ce cas, spécifiez les classes virtualisées dans le fichier rules.xml de l'agent et redémarrez-le.
Autres problèmes liés au VSE Java
Si vous rencontrez des problèmes (utilisation de ressource fonctionnelle ou anormale) lors de l'utilisation de VSE Java, désactivez CAI côté agent.
Vous pouvez désactiver CAI en désactivant la propriété Auto-start (Démarrage automatique). Puis, redémarrez ensuite la machine virtuelle Java.
Vous pouvez configurer cette propriété à partir de la fenêtre Agents du portail DevTest. La propriété s'affiche dans l'onglet Settings (Paramètres).
Ne désactivez pas CAI côté intermédiaire, sans quoi le VSE Java arrêtera de fonctionner complètement.
La fonctionnalité de scénario ne fonctionne pas.
En premier lieu, vérifiez que l'agent est connecté à un intermédiaire.
Si c'est le cas, examinez la source HTML de la page problématique. Vérifiez que le bas de la page contient un bloc JavaScript facilement reconnaissable aux noms de variables utilisés (par exemple : com_itko_pathfinder_defectcapture_xxx). Si ce bloc est manquant, examinez le journal d'agent et recherchez d'éventuelles exceptions. L'absence du bloc peut également être expliquée par l'une des raisons suivantes :
Si le bloc est présent, vérifiez si un serveur Web natif (par exemple, Apache) ou un équilibreur de charge est présent en face du conteneur Java. Si c'est le cas, configurez-le de sorte à envoyer la demande de JavaScript CAI et fichiers de ressources au conteneur Java. Ces fichiers contiendront le terme defectcapture dans leur URL. En général, les administrateurs informatiques connaissent la procédure de cette tâche.
DevTest est configuré pour utiliser une base de données DB2 IBM. Dans le portail DevTest, j'ai sélectionné un noeud JDBC dans un graphique de chemin. Les colonnes Statements et Connection Url sont vides.
Désactivez la diffusion en continu progressive en ajoutant la chaîne progressiveStreaming=2 à l'URL de connexion JDBC. Par exemple :
lisadb.pool.common.url=jdbc:db2://myhostname:50000/dbname:progressiveStreaming=2;
|
Copyright © 2014 CA Technologies.
Tous droits réservés.
|
|