Cette section traite des problèmes connus liés à l'administration et les solutions associées.
Par défaut, $INSTALL/lib/package-appclient.xml contient une valeur codée en dur pour la variable AS_ACC_CONFIG de domain1 pointé par asenv.conf. Si domain1 est supprimé et qu'un autre domaine est créé, la variable AS_ACC_CONFIG n'est pas mise à jour avec le nouveau nom de domaine, ce qui provoque l'échec du script package-appclient.
Effectuez l'une des opérations suivantes :
Conservez domain1 intact et créez vos propres domaines en tenant compte de celui-ci.
Supprimez domain1 et remplacez la valeur codée en dur de domain1 dans $INSTALL/lib/package-appclient.xml par le nouveau nom de domaine.
Cette procédure devra être effectuée à chaque création d'un nouveau domaine si domain1 n'est pas présent.
La mise en miroir d'un domaine sur la même installation d'Application Server ne peut pas être effectuée à l'aide des commandes backup-domain et restore-domain car il est impossible de restaurer ce domaine en utilisant un autre nom que celui d'origine, même si la commande asadmin restore-domain propose une option de renommage. L'attribution d'un nouveau nom au domaine sauvegardé semble avoir été correctement effectuée, mais les tentatives de démarrage de ce domaine n'aboutissent pas, car les entrées liées à la configuration du domaine n'ont pas été modifiées et les commandes startserv et stopserv utilisent toujours le nom de domaine d'origine pour définir les chemins.
Le nom de domaine utilisé pour restore-domain doit être identique à celui utilisé pour la commande d'origine backup-domain. Les commandes backup-domain et restore-domain sur Application Server 8.1 peuvent uniquement être utilisées pour sauvegarder et restaurer le même domaine sur la même machine.
La version J2SE1.4.x, 5.0 ou version ultérieure peut être configurée sur Application Server. La fonction de démarrage d'un agent JMX est intégrée à la plate-forme J2SE 5.0. Un agent est activé lorsque vous définissez explicitement les propriétés système lors du démarrage du serveur.
Voici quelques exemples de valeurs :
name="com.sun.management.jmxremote" value="true" name="com.sun.management.jmxremote.port" value="9999" name="com.sun.management.jmxremote.authenticate" value="false" name="com.sun.management.jmxremote.ssl" value="false" |
Une fois les propriétés JMX configurées et le serveur démarré, un nouveau serveur jmx-connector est démarré dans la machine virtuelle d'Application Server. L'un des effets secondaires non désirés de cette opération est que celle-ci nuit aux fonctions d'administration ; la console d'administration d'Application Server et l'interface de ligne de commande peuvent alors produire des résultats inattendus. Le problème provient du fait qu'il existe des conflits entre le serveur jmx-connector intégré et le nouveau serveur jmx-connector.
Si vous utilisez jconsole (ou tout autre client JMX-compliant), pensez à réutiliser le serveur de connecteurs JMX standard lancé au démarrage d'Application Server.
Lorsque le serveur démarre, une ligne similaire à celle indiquée ci-dessous s'affiche dans le journaldu serveur. Vous pouvez vous connecter à l'URL JMXService spécifié et exécutez les mêmes opérations de configuration/gestion après avoir fourni des données d'authentification correctes ; par exemple :
[#|2004-11-24T17:49:08.203-0800|INFO|sun-appserver-ee8.1| javax.enterprise.system.tools.admin|_ThreadID=10;|ADM1501: Here is the JMXServiceURL for the JMXConnectorServer: [service:jmx:rmi:///jndi/rmi://hostname:8686/management/ rmi-jmx-connector]. This is where the remote administrative clients should connect using the JSR 160 JMX Connectors.|#] |
Pour plus d'informations, reportez-vous au manuel Sun Java System Application Server 9.1 Administration Guide .
Si vous exécutez la commande asadmin restore-domain lorsque vous êtes connecté en tant qu'utilisateur A, les scripts seront dotés des autorisations 744 (rwxr--r--
). Si vous tentez par la suite de démarrer ou d'arrêter un domaine en tant qu'utilisateur B, l'opération risque d'échouer (même si B désigne l'utilisateur root), car les scripts ne peuvent être exécutés que par l'utilisateur A.
Modifiez les autorisations des scripts :
chmod 755 appserv/domains/domain-name/bin/* |
Lors de la configuration de l'équilibreur de charge avec une application dotée d'un module EJB qui exporte l'URL d'un service Web, la racine du contexte du service Web ne figure pas dans le fichier loadbalancer.xml en résultant.
Modifiez le fichier loadbalancer.xml de manière à ajouter le module Web manquant comme suit :
<web-module context-root="context-root-name" disable-timeout-in-minutes="30" enabled="true"/> |
Remplacez la valeur context-root-name par le nom de la racine de contexte du service Web présenté comme EJB.
Renommez le script existant <as_install> /bin/asant en asant.bak.
Copiez le fichier asant.template de <as_install> /lib/install/templates/ee (pour la version SE/EE) dans le répertoire <as_install>/bin/ et renommez-le en asant.
Modifiez le script copié <as_install> /bin/asant, en remplaçant le jeton %CONFIG_HOME% par <as_install>/config.
En cas de modifications manuelles apportées au fichier asant.bak , fusionnez-les dans le nouveau script asant.
Le fichier .asadmintruststore n'est pas présenté dans la documentation d'Application Server. Si ce fichier n'existe pas dans le répertoire home de l'administrateur, vous pouvez rencontrer de graves bogues lors de la mise à niveau d'applications hébergées sur le serveur.
Si possible, la commande asadmin start-domain domain1 doit être exécutée par l'utilisateur qui a installé le serveur.
Dans le cas contraire, le fichier .asadmintruststore doit être déplacé ou copié du répertoire home de l'utilisateur qui a procédé à l'installation dans le répertoire home de l'utilisateur qui l'exécute.
Notez que si le fichier est déplacé (et non copié) du répertoire home de l'utilisateur "installateur" dans le répertoire home de l'utilisateur "exécuteur", vous pouvez rencontrer des problèmes de mise à niveau de l'application, tels que décrits dans les bogues 6309079, 6310428 et 6312869 car l'utilisateur de mise à niveau/installation (généralement root dans Java ES) ne disposera plus du fichier .asadminstruststore dans son répertoire home.
Le mode d'intégration MQ par défaut d'une instance clusterisée d'Application Server est LOCAL. Lorsqu'Application Server est installé dans un emplacement (PATH) long (c'est-à-dire « non court »), imqbrokerscv.exe s'arrête brutalement au démarrage de l'instance clusterisée. Le problème provient d'une allocation de mémoire incorrecte dans imqbrokersvc.
Il est nécessaire de modifier le type de service JMS pour l'instance clusterisée, de la valeur par défaut LOCAL sur REMOTE. Avec cette configuration, toutes les instances pointent vers le courtier DAS. Suivez les instructions ci-dessous pour configurer un cluster en mode REMOTE.
Avec le mode REMOTE, toutes les instances n'utilisent qu'un seul courtier (DAS), par conséquent aucun cluster de courtier n'est créé au démarrage du cluster d'Application Server. Pour plus d'informations, reportez-vous à la section Auto-clustering de la section 4.1, division iii de la page unique sur http://www.glassfishwiki.org/gfwiki/attach/OnePagersOrFunctionalSpecs/as-mq-integration-gfv2.txt. La fonctionnalité susmentionnée ne sera pas disponible.
Modifiez le port et le fichier de mots de passe selon votre environnement. Notez que dans les instructions ci-dessous, le nom du cluster est racluster, le port d'administration DAS est 5858 et le port JMS DAS 7676 .
Modifiez la configuration du cluster, en changeant le type JMS sur REMOTE .
$AS91_HOME/bin/asadmin.bat set --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file racluster.jms-service.type=REMOTE |
Créez un hôte JMS correspondant à l'hôte JMS DAS.
$AS91_HOME/bin/asadmin.bat create-jms-host --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file --target racluster --mqhost localhost --mqport 7676 \ --mquser admin --mqpassword admin dashost |
Définissez l'hôte JMS DAS créé à l'étape précédente comme le nouvel hôte JMS par défaut.
$AS91_HOME/bin/asadmin.bat set --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file racluster.jms-service.default-jms-host=dashost |
Accédez à Configurations->nom_cluster-config->Java Message Service->Hôtes JMS.
Cliquez sur Nouveau pour créer un nouvel hôte JMS ; nommez-le dashost.
Entrez les paramètres de configuration correspondant au service JMS pour le DAS ; les valeurs par défaut sont les suivantes :
Nom d'hôte : localhost
Port : 7676
Utilisateur administrateur : admin
Mot de passe : admin
Modifiez ces paramètres au besoin pour votre service JMS DAS.
Retournez à l'onglet Java Message Service, puis modifiez le type de service JMS sur REMOTE (défini sur LOCAL par défaut).
Choisissez dashost à partir de la liste déroulante default-jms-host.
Enregistrez vos modifications, puis démarrez votre agent de nœud ou votre cluster.
Lorsque vous essayez d'afficher un diagramme de la page de contrôle des statistiques de journalisation à l'aide d'un navigateur non pris en charge, le message d'erreur suivant peut s'afficher :
Error loading jmaki.widgets.jmaki.charting.line.Widget : id=form1:jmaki_chart11 Script: http://easqelx5.red.iplanet.com:4848/resources/jmaki/charting/ \ line/component.js (line:5437). Message: area.initialize is not a function |
Utilisez un navigateur pris en charge. Reportez-vous à la section Navigateurs pour obtenir la liste des navigateurs pris en charge par Application Server 9.1.
Dans les trois dernières versions principales d'Application Server, le port d'administration par défaut a été modifié. De manière plus spécifique, les ports d'administration par défaut dans 7.x, 8. x et 9.x sont les suivants :
AS 7.x : 4848
AS 8.x : 4849
AS 9.x : 4848
Il ne s'agit pas d'un bogue mais d'un fait à prendre en compte. Le port d'administration par défaut est simplement une recommandation. Nous pensons d'ailleurs que les prochaines versions d'Application Server conserveront le port 4848.