Talons de dépannage

Vous pouvez résoudre les problèmes courants que vous pourriez rencontrer lors de l’utilisation des stubs.

Table 1. Résolutions des problèmes avec les stubs
Problem	Resolution
Le stub génère le message d'erreur suivant dans sa sortie de console: `[CRRIT1717E] The socket associated with the request message is no longer available.`	Cette erreur apparaît lorsqu'une action Envoyer la réponse ne parvient pas à communiquer avec le système client qui a émis le message de demande. La cause la plus probable est que le client a déjà reçu une réponse d'une autre action Envoyer la réponse dans le stub et que sa connexion est fermée. Cette situation peut se produire lorsque plusieurs événements se trouvent dans le même stub HTTP qui traite les mêmes messages. Si la configuration du filtrage permet à plusieurs événements de répondre au même message, un seul d'entre eux réussit. La deuxième action Envoyer la réponse échoue avec cette erreur car le client est déconnecté. Vérifiez votre configuration de filtrage pour empêcher plusieurs correspondances dans différents événements. Envisagez de reconcevoir le stub pour avoir un seul événement pour ces messages. Dupliquez l'événement pour chaque type de message et configurez le filtrage.
Le stub n'enregistre pas les événements.	Dans le tableau de bord Environnements pour IBM® DevOps Test Virtualization Control Panel (Test Virtualization Control Panel) (ou dans IBM DevOps Test Integrations and APIs (Test Integrations and APIs) ), vérifiez que le stub a été configuré pour consigner les événements. Alternativement, si `localhost` a été configuré comme URL de journalisation, la journalisation ne peut pas fonctionner si le stub est exécuté sur un autre agent.
Test Integrations and APIs Impossible de configurer le routage vers le stub.	Lors du démarrage d'un stub dans Test Integrations and APIs, vous pourriez voir l'erreur suivante sur la console: `[CRRIT8674E] Unable to configure routing to the stub: 409 Conflict.` Cette erreur peut également apparaître dans le IBM DevOps Test Integrations and APIs Agent (Test Integrations and APIs Agent) fichier journal. Le problème se produit lorsque vous créez deux stubs avec le même transport et la même opération et que vous essayez d’exécuter les deux stubs simultanément. La solution consiste à n’exécuter qu’un seul stub à la fois. Vous pouvez supprimer l'un des talons.
Le stub fonctionne très lentement.	Si la journalisation est activée, vérifiez que la connexion à la base de données de résultats peut être établie et présente des performances suffisantes compte tenu du volume de messages écrits par le stub.
Le stub exécuté sur l'agent ne peut pas se connecter à la base de données de résultats.	Assurez-vous que l'ordinateur exécutant le stub et l'ordinateur exécutant Test Virtualization Control Panel disposer de la connexion réseau requise pour accéder à la base de données des résultats du projet.
Le pilote de base de données requis est manquant.	Si vous utilisez un pilote MySQL, assurez-vous qu'il a été correctement installé. Si vous utilisez un pilote JDBC non standard, assurez-vous qu'il est inclus dans le `CLASSPATH` de l'ordinateur où Test Virtualization Control Panel est installé.
Le trafic n’est pas acheminé vers le stub.	En cas de problème, vérifiez les éléments suivants: Vérifiez la règle de routage dans le Test Virtualization Control Panel, Tableau de bord des infrastructures. Si la règle est manquante ou si son nom d'hôte ou son adresse IP est incorrect, corrigez-la, puis redémarrez le stub. Vérifiez la sortie de la console stub disponible à l'emplacement contenant les journaux de l'agent. Lors du démarrage du stub, un message d'avertissement, `"Failed to resolve hostname"` pourrait être affiché. Ce problème se produit si la recherche DNS échoue et que les règles de routage ne sont pas créées correctement. Pour résoudre ce problème, vérifiez si vous êtes connecté au bon réseau, en particulier si le stub ou l'environnement utilise des noms d'hôte provenant d'un réseau privé. Si le problème persiste, contactez l'administrateur système ou réseau pour enquêter sur les problèmes de résolution DNS.
Le proxy ou l'interception du transport n'achemine pas le trafic vers le stub.	Lorsque vous démarrez les stubs, ils attendent que les proxys externes récupèrent les règles de configuration de routage du serveur avant de pouvoir terminer le processus d'initialisation et démarrer les étapes principales. Par conséquent, lorsque vous exécutez des suites de tests qui utilisent des stubs, les tests ne démarrent pas tant que les proxys n'ont pas reçu leurs règles de configuration. En cas de problème, vérifiez les éléments suivants: Le proxy est enregistré pour le domaine sélectionné dans le Test Integrations and APIs les paramètres du projet et l'environnement actuel du projet ou le proxy sont enregistrés pour tous les domaines et environnements. Le proxy est en cours d'exécution et il n'y a aucun problème de réseau. Vérifiez l'état du proxy sur le Tableau de bord des infrastructures dans Test Virtualization Control Panel ou dans les journaux du proxy HTTP/TCP. Voici un exemple de sortie de la console stub qui indique que la règle de configuration n'a pas atteint le proxy externe dans le temps imparti: [03/02/2015 11:41:21.382 AM] - - - - Starting initialization - - - - [03/02/2015 11:41:21.382 AM] [Infrastructure] Sending routing configuration to Test Virtualization Control Panel... [03/02/2015 11:41:28.394 AM] [Infrastructure] [CRRIT8674E] Unable to configure routing to the stub: None of the available connected agents have been successfully configured. There are currently 1 connected agent(s) registered with Test Virtualization Control Panel. [03/02/2015 11:41:28.394 AM] [Infrastructure] Application traffic in the environment will not be automatically routed to the stub. Dans cet exemple, un seul proxy est enregistré auprès de Test Virtualization Control Panel. Soit le processus du proxy s'est arrêté et son enregistrement n'a pas expiré, soit le proxy n'a pas pu se connecter à Test Virtualization Control Panel, et donc les règles de proxy n'ont pas pu être appliquées dans le temps imparti. Si aucun mandataire n'est enregistré auprès Test Virtualization Control Panel, les messages suivants s'affichent dans la sortie de la console stub: [03/02/2015 11:45:01.861 AM] - - - - Starting initialization - - - - [03/02/2015 11:45:01.861 AM] [Infrastructure] Sending routing configuration to Test Virtualization Control Panel... [03/02/2015 11:45:01.873 AM] [Infrastructure] [CRRIT8674E] Unable to configure routing to the stub: There are no connected HTTP(S) agents registered with Test Virtualization Control Panel in domain "default" and environment "example.com with proxy". Please check the configuration of the agents and control panel. [03/02/2015 11:45:01.873 AM] [Infrastructure] Application traffic in the environment will not be automatically routed to the stub. Pour plus de conseils de dépannage, consultez les liens associés à la fin de la page.
Publication de talons de Test Integrations and APIs à Test Virtualization Control Panel échoue avec l'erreur suivante: `Error: 507 (Insufficient Storage).`	Libérez de l'espace sur le disque utilisé par Test Virtualization Control Panel. Pour savoir quel emplacement de disque est utilisé, regardez dans lecontainer.server.properties dossier pour leworkingDirectory propriété. L'emplacement par défaut ducontainer.server.properties le fichier est: Systèmes Windows: `C:\Program Files\IBM\DevOpsTestControlPanel\usr\servers\defaultServer\apps\RTCP.war\WEB-INF\classes` Systèmes autres que Windows: `/opt/IBM/DevOpsTestControlPanel/usr/servers/defaultServer/apps/RTCP.war/WEB-INF/classes`
Le numéro de port TCP configuré dans le stub est déjà utilisé.	Utilisez lenetstat commande pour voir quels numéros de port sont utilisés par quels processus. Si les programmes clients accèdent au stub à l'aide du proxy TCP/HTTP, vous pouvez ignorer ce message d'avertissement. Le proxy achemine correctement les messages vers le stub même s'il utilise un numéro de port temporaire. Toutefois, si vous devez exécuter le stub sur un port fixe, utilisez les résultats du diagnostic pour effectuer l'une des actions suivantes: Configurez un numéro de port différent pour le stub. Soit vous sélectionnez un autre transport pour l'opération dansÉcole d'architecture > Vue logique ou modifiez le transport existant pour utiliser un numéro de port différent. Terminez le programme qui utilise le numéro de port et redémarrez le stub.
Le stub ne s'ouvre pas dans l'éditeur de stub.	Vous avez créé un stub à partir d'une opération qui est une action d'abonnement. Le stub a l'action de messagerie opposée, qui est une action de publication. Ce type de stub ne peut pas être modifié dans l'éditeur de stub. Vous devez le modifier à l'aide de l'éditeur de tests, qui est normalement utilisé pour modifier les séquences de tests. Lorsque vous créez un stub, ses actions de messagerie sont l'inverse de l'opération afin de simuler la fin serveur de la communication. Par exemple, une opération Envoyer une demande/Recevoir une réponse donne un stub du formulaire Recevoir une demande/Envoyer une réponse. Ce type de stub a une action de changement de message et est modifié par défaut dans l'éditeur de stub. Vous pouvez le modifier dans l'éditeur de tests en cliquant avec le bouton droit sur l'objet dans l'arborescence Test Factory et en sélectionnantOuvrir avec > Éditeur de tests. Cette option n’est pas recommandée pour les talons plus complexes. Pour une opération d'abonnement, l'action de stub est Publier. Vous ne pouvez pas modifier cette action dans l'éditeur de stub car elle attend un message d'entrée. La modification de ce type de stub ouvre l'éditeur de test et vous pouvez voir l'action Publier pour un test.
La règle de routage de stub utilise une adresse réseau incorrecte.	Lorsque vous exécutez un stub sur un système doté de plusieurs adresses réseau, la règle de routage envoyée à Test Virtualization Control Panel pourrait utiliser la mauvaise adresse réseau. Si l'adresse réseau utilisée n'est pas accessible depuis le proxy, les messages ne peuvent pas être acheminés vers le stub. Ajoutez la variable d'environnement système suivante sur le système qui exécute le stub pour forcer l'adresse de règle requise: `RULE_HOST=192.168.1.1` Redémarrez le système pour utiliser le paramètre.
Les stubs ne démarrent pas sur les moteurs configurés sur Test Virtualization Control Panel.	Lorsque vous avez configuré plus de 10 moteurs pour démarrer simultanément sur Test Virtualization Control Panel sur lequel les stubs doivent être exécutés, vous rencontrez ce problème. Pour résoudre ce problème, vous devez modifier leAgent.config fichier qui se trouve dans le<Agent_installation_folder>/config répertoire et modifiez les valeurs suivantes: Changer la valeur demaxConcurrentStarts au nombre de moteurs que vous souhaitez démarrer simultanément. Remplacez la valeur de concurrencyPeriodSecs par le délai pendant lequel tous les moteurs doivent démarrer après le démarrage du premier moteur. Vous devez enregistrer la configuration modifiée et redémarrer l'agent avant de démarrer les stubs.