L'utilitaire de ligne de commande du ServiceManager (Gestionnaire de services) permet d'effectuer diverses actions avec un registre, un coordinateur, un simulateur, ou le serveur de VSE.
ServiceManager [--command]=service-name
service-name correspond au nom du service à affecter.
Vous pouvez répéter la paire commande-nom.
Pour rechercher le nom, placez une clé lisa.properties entre accolades doubles. Par exemple :
{{lisa.registryName}}
Exemple de noms de service :
Affiche le texte d'aide.
Affiche un message de statut du service. Pour que service-name renvoie des messages de statut pour tous les services enregistrés, saisissez all.
Conserve le service en mémoire, mais actualise son état.
Indique au service de se finaliser.
Initialise un service à distance.
Indique au service de générer un fil de discussion (trace de pile) pour les diagnostics.
Indique au simulateur de renvoyer une liste des appareils mobiles connectés.
Indique au service de créer un fichier .hprof pour les diagnostics de mémoire.
Indique au service de forcer le nettoyage de la mémoire Java.
Crée un fichier .zip qui contient des fichiers de diagnostic pour le service. Si le service est un registre, le fichier .zip contiendra également des fichiers de diagnostic pour tous les coordinateurs, simulateurs et serveurs de VSE connectés. En règle générale, vous utilisez cette option lorsque vous y êtes invité par le service de support.
loglevel
Cette option inclut également un paramètre facultatif, secondaire, appelé loglevel, suivi par l'un des mots clés loglevel suivants : error (erreur), warn (avertissement), info, debug (débogage), trace.
Par exemple, ServiceManager -d tcp://10.1.1.23:2010/Registry loglevel debug définit le niveau de journalisation de tous les composants, y compris des agents, sur le niveau debug (débogage). Le gestionnaire de services écrit alors le message suivant :
Log levels set to debug (Niveaux de journalisation définis sur débogage). Run your repro steps, then press return to restore log levels and capture diagnostic (Exécutez vos étapes de reproduction, puis appuyez sur Retour pour restaurer des niveaux de journalisation et capturer le diagnostic).
Le fichier .zip généré contient des journaux de niveau de journalisation debug pour tous les composants connectés, les fils de discussion, les informations de licence et les propriétés. Ce fichier .zip contient également les journaux pour chaque agent connecté à l'intermédiaire du registre.
Remarque : Si la commande -d est envoyée vers un VSE, un coordinateur ou un serveur de simulation, seuls les journaux et le diagnostic pour ce composant seront inclus dans le fichier .zip.
Les agents n'ont pas de niveau de journal de trace, mais le niveau de journalisation dev (développement) est similaire et traité comme tel.
Utilisez cette commande pour spécifier votre nom d'utilisateur.
Utilisez cette commande pour spécifier votre mot de passe.
Imprime le numéro de version.
Utilisée avec la commande initialize pour spécifier un registre auquel se connecter
Utilisée avec la commande initialize pour spécifier un nom du composant
Utilisée avec initialize pour spécifier un nom de laboratoire à créer.
Utilisée avec la commande initialize pour spécifier une ID d'application de serveur
Exemple :
Si vous voulez nommer un simulateur MySim, puis le connecter au registre MyRegistry et démarrer un nouveau laboratoire nommé MyDevLab, saisissez :
./SimulatorService -n MySim -m tcp://1.2.3.4:2010/MyRegistry -l MyDevLab
Pour ajouter un deuxième simulateur à ce laboratoire :
./SimulatorService -component-name=MySecondSim -registry-name=tc;"//1.2.3.4:2010/MyRegistry -lab-name=MyDevLab
Pour ajouter un VSE à ce registre, mais dans un laboratoire différent :
./VirtualServiceEnvironment -n CoreServices -m tcp://1.2.3.4:2010/MyRegistry -l QA
Dans l'exemple suivant, le statut du registre est vérifié.
ServiceManager -s Registry Coordinator Servers: 1 Simulator Servers: 2 VSEs: 1 Running vusers: 0 Labs: 1 Memory used 76mb, allocated 155mb, max 253mb (30%) labSims: 2 labVSEs: 1 labCoords: 1
Dans l'exemple suivant, le statut de l'ensemble des services enregistrés est vérifié.
Coordinator Server: tcp://bdert-mbp.local:2011/Coordinator OK: 1 Coordinators running. Memory used 223mb, allocated 461mb, max 910mb (24%) Our cpu usage 0%, system cpu used 8% Simulator Server: tcp://bdert-mbp.local:2014/Simulator OK: 1 Simulators running. Memory used 301mb, allocated 437mb, max 910mb (33%) Our cpu usage 0%, system cpu used 8%
Dans l'exemple suivant, le registre s'arrête.
ServiceManager -o Registry Sending stop request to Registry.
Dans l'exemple suivant, un fil de discussion pour le serveur de VSE est généré.
ServiceManager --threaddump=tcp://remote.host.com:2013/VSE < a bunch of stack traces >
Dans l'exemple suivant, un nettoyage de la mémoire Java du serveur de VSE est forcé.
ServiceManager --gc=VSE After GC: Memory used 55mb, allocated 225mb, max 246mb (22%)
Dans l'exemple suivant, un fichier .zip contenant des journaux de niveau trace pour tous les composants connectés au registre est généré.
ServiceManager --diagnostic=Registry loglevel TRACE
Dans l'exemple suivant, un fichier .zip contenant des journaux de niveau debug (débogage) pour le simulateur est généré.
ServiceManager -d Simulator loglevel debug
|
Copyright © 2014 CA Technologies.
Tous droits réservés.
|
|