Cette section décrit les problèmes connus relatifs à Sun Java System serveur d'application Environment Enterprise 8.1 2005Q2 et présente les solutions associées. Si aucune plate-forme particulière n'est spécifiée, le problème s'applique à toutes les plates-formes. Voici les sujets abordés :
Cette section traite des problèmes connus liés à l'administration et les solutions associées.
Cette section décrit les problèmes connus relatifs au serveur Web Apache et au plug-in de l'équilibreur de charge et présente les solutions associées.
ID du bogue |
Résumé |
---|---|
6306784 |
Le manuel High-Availability Administration Guide contient des instructions erronées sur l'utilisation de openssl avec Apache. Solution Lors de la compilation et de la création de openssl, exécutez les commandes suivantes : cd openssl-0.9.7e config make En outre, avec Apache 1.3, le nom du répertoire de la source mod_ssl varie en fonction de la version d'Apache utilisée. Par exemple, pour Apache 1.3.33, le nom est mod_ssl-2.8.22-1.3.33. |
6307976 |
Le manuel High-Availability Administration Guide ne contient aucune instruction relative à l'utilisation d'un certificat pour Apache 2.0. Solution Pour exécuter la sécurité Apache, vous devez utiliser un certificat. Pour obtenir des instructions sur l'obtention d'un certificat auprès d'une autorité de certification, consultez les informations sur les certificats à l'adresse modssl FAQ. |
6308021 |
Démarrage du serveur Web Apache uniquement en tant qu'utilisateur root. Solution Sous Solaris, si Application Server a été installé par un utilisateur root, vous devez démarrer le serveur Web Apache en vous connectant en tant qu'utilisateur root. Les installations Java Enterprise System sont effectuées par des utilisateurs root. Avec Apache 2.0, après avoir démarré sous une connexion d'utilisateur root, il bascule et s'exécute sous la connexion utilisateur que vous avez définie. Vous pouvez définir cet utilisateur dans le fichier /conf/httpd.conf. Pour démarrer le serveur en tant qu'utilisateur root, sur la plupart des systèmes, vous devez modifier le fichier httpd.conf afin de définir le groupe approprié. Remplacez la ligne : Group #-1 par Group nobody Vous trouverez d'autres informations sur les utilisateurs et les groupes dans le fichier httpd.conf. |
6308043 |
Instructions supplémentaires sur l'utilisation de openssl avec Apache Web Server 2.0 sous Solaris. Après avoir installé Apache 2.0 et le plug-in de l'équilibreur de charge, modifiez les fichiers ssl.conf et sll-std.conf de la manière suivante : Remplacez la ligne : <VirtualHost _default_:9191> par <VirtualHost machine_name:9191> où machine_name correspond au nom de la machine et 9191 au numéro du port de sécurité. |
Cette section décrit les problèmes connus des clients d'application et les solutions associées.
ID du bogue |
Résumé |
---|---|
6193556 |
La bibliothèque JAR fournie avec les archives du client d'application écrase le fichier manifeste Si vous possédez un fichier JAR de niveau supérieur dans votre JAR client (dans notre cas, reporter.jar), le fichier manifeste de ce JAR écrase celui du JAR client lorsque vous déployez ce dernier. Solution Aucune pour l'instant. |
6373043 |
Les technologies de contenu dynamique, comme CGI-bin et SHTML, ne sont plus prises en charge. Solution Utilisez plutôt des technologies JSP et services Web. |
Cette section décrit les problèmes connus du pilote Sun JDBC intégré et les solutions associées.
ID du bogue |
Résumé |
---|---|
6165970 |
Les applications utilisant le niveau d'isolement TRANSACTION_SERIALIZABLE avec le pilote Sun intégré de Microsoft SQL Server risquent de s'interrompre lors de l'utilisation d'une instruction préparée pour la mise à jour si deux transactions parallèles sont en cours d'exécution et que l'une d'entre elles est annulée. Pour définir le niveau d'isolement d'une connexion, le pool de connexions correspondant doit être créé sur le même niveau d'isolement. Pour obtenir plus d'informations sur la configuration des pools de connexions, reportez-vous au manuel Administration Guide. Solution Aucune pour l'instant. |
6170432 |
Erreurs PreparedStatement. Description #1 Si une application génère plus de 3000 objets PreparedStatement au cours d'une transaction, l'erreur suivante peut se produire avec DB2 : [sunm][DB2 JDBC Driver] No more available statements.Please recreate your package with a larger dynamicSections value. Solution #1 Ajoutez les propriétés suivantes à la définition de pool de connexions afin que le pilote puisse rééditer les liens des packages DB2 avec une valeur dynamicSections supérieure : createDefaultPackage=true replacePackage=true dynamicSections=1000 Pour obtenir plus de détails sur la configuration des pools de connexions, reportez-vous au manuel Administration Guide. Description #2 En liaison avec l'erreur PrepardStatement mentionnée ci-dessus, le message d'erreur suivant peut également être généré : [sunm][DB2 JDBC Driver][DB2]Virtual storage or database resource is not available. Solution #2 Augmentez la valeur du paramètre de configuration APPLHEAPSZ pour le serveur DB2. 4096 constitue une valeur correcte. Description #3 Niveau d'isolement TRANSACTION_SERIALIZABLE. Si votre application utilise le niveau d'isolement TRANSACTION_SERIALIZABLE avec l'un des paramètres indiqués ci-dessus, elle peut rester bloquée en tentant d'obtenir la connexion. Solution #3 Pour définir le niveau d'isolement d'une connexion, le pool de connexions correspondant doit être créé sur le même niveau d'isolement. Pour obtenir des instructions, reportez-vous au manuel Administration Guide. |
6189199 |
Problèmes rencontrés lors du paramétrage du niveau d'isolement à l'aide du pilote Sun intégré pour Sybase Adaptive Server
Solution Aucune pour l'instant. |
6247468 |
Sous Solaris 10 et Enterprise Linux 3.0, le pilote intégré JDBC Sun pour Oracle ne permet pas la création d'une connexion. Solution Définissez la propriété ci-dessous dans le pool de connexions JDBC lors de l'utilisation de la source de données Oracle SUN JDBC (com.sun.sql.jdbcx.oracle.OracleDataSource): <property name="serverType" value="dedicated"/> La valeur de la propriété dépend de la configuration du listener du serveur Oracle. Si le listener est configuré en mode partagé, la valeur "partagé" qui doit alors s'afficher dans l'exemple ci-dessus doit être remplacée par la valeur "dedicated". |
6554602 |
Le démarrage avec les pilotes JDBC 10.2 , comprenant plusieurs fichiers jar JDBC dans CLASSPATH, peut entraîner une exception java.lang.SecurityException: Sealing violation exception. Pour de plus amples informations, reportez-vous à l'ID du document Oracle suivant : Remarque : 405446 Objet : Le pilote JDBC 10.2 utilise les fichiers JAR verrouillés et peut entraîner une violation de verrouillage pour l'exception de sécurité Solution (conseillé par Oracle) Assurez-vous que CLASSPATH ne comprend qu'un seul fichier JAR pour le pilote JDBC. |
Cette section décrit les problèmes connus de l'architecture de connecteurs J2EE et les solutions associées.
ID du bogue |
Résumé |
---|---|
6188343 |
Après avoir redémarré une instance DAS, l'annulation du déploiement du module connecteur échoue lorsque l'option en cascade est définie sur false Dans ce scénario, un module connecteur autonome ou imbriqué est déployé dans l'instance DAS et les pools de connexions du connecteur, et des ressources sont créées pour le module déployé. Après le redémarrage de l'instance DAS, l'annulation du déploiement du connecteur échoue lorsque l'option en cascade est paramétrée sur false et l'exception suivante est générée : [#|2004-10-31T19:52:23.049-0800|INFO|sun-appserver-ee8.1|javax.enterprise.system .core|_ThreadID=14;|CORE5023: Error while unloading application [foo]|#] Solution Utilisez l'annulation de déploiement en cascade (en définissant l'option cascade sur true) afin d'annuler le déploiement des connecteurs autonomes et imbriqués après le redémarrage de l'instance DAS. |
Cette section décrit les problèmes détectés dans la documentation et les solutions associées.
ID du bogue |
Résumé |
||
---|---|---|---|
Plusieurs ID |
Incohérences dans Javadoc. Une documentation Javadoc est absente ou incorrecte pour plusieurs interfaces et méthodes AMX :
|
||
6265624 |
L'outil ANT intégré génère l'exception java.lang.NoClassDefFoundError. L'exception suivante est générée dans le thread principal "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher. Solution Il est conseillé de ne pas utiliser l'outil ANT intégré ailleurs que dans serveur d'application. |
||
6486123 |
La documentation sur la réalisation d'une connexion physique à partir d'une connexion enroulée est désormais erronée. Conséquence d'autres défaillances (probablement 6295215), le code fourni dans la section Obtaining a Physical Connection from a Wrapped Connection du Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide du Chapitre 11, Using the JDBC API for Database Access du Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide est désormais erroné. La ligne :
est maintenant remplacée par :
|
Cette section décrit les problèmes connus de base de données haute disponibilité (HADB) et les solutions associées.
ID du bogue |
Résumé |
|||
---|---|---|---|---|
Aucun ID |
Configuration HADB avec double réseau Sous Solaris SPARC, les bases de données HADB configurées avec double réseau fonctionnent parfaitement sur deux sous-réseaux. Cependant, du fait de problèmes au niveau du système d'exploitation ou des pilotes réseau sur certaines plates-formes matérielles, les plates-formes Solaris x86 et Linux ne gèrent pas toujours correctement les doubles réseaux. Cela crée les problèmes suivants pour la base de données HADB:
|
|||
Aucun ID |
Échec de la création de la base de données HADB La création d'une base de données risque d'échouer en générant l'erreur suivante, indiquant que le nombre de segments de mémoire partagée disponibles est insuffisant : HADB-E-21054: System resource is unavailable: HADB-S-05512: Attaching shared memory segment with key "xxxxx" failed, OS status=24 OS error message: Too many open files. Solution Vérifiez que la mémoire partagée est correctement configurée. En particulier, sous Solaris 8, inspectez le fichier /etc/system et assurez-vous que la valeur de la variable shmsys:shminfo_shmseg est au moins six fois supérieure au nombre de nœuds par hôte. |
|||
5052548 |
Segments de mémoire partagée bloqués et ne pouvant pas être évacués. HADB 4.3-0.16 et version ultérieure est configuré pour utiliser une mémoire partagée personnelle lorsqu'il crée et associe ses segments de mémoire partagée (avec l'indicateur SHM_SHARE_MMU). L'utilisation de cet indicateur bloque essentiellement les segments de mémoire partagée d'une mémoire physique et empêche leur évacuation. Ceci entraîne des problèmes dans des installations sur des machines bas de gamme. Par conséquent, si un développeur dispose d'une machine dotée d'une mémoire de 512 Mo et d'espace de swap disponible et qu'il utilise serveur d'application7.0 EE, puis la version 7.1 EE ou ultérieure, il rencontrera des problèmes de configuration du cluster clsetup par défaut (qui crée deux nœuds HADB, chacun doté d'une devicesize de 512), ceci entraînant une RAM physique insuffisante pour prendre en charge la mémoire partagée nécessaire aux deux nœuds. Solution Vérifiez que vous disposez de la quantité de mémoire recommandée pour accueillir Application Server et HADB. Reportez-vous à la section Configuration requise pour HADB et plates-formes prises en charge pour plus d'informations. |
|||
5091280 |
hadbm set ne vérifie pas la disponibilité des ressources (espace disque et mémoire). Lorsque vous augmentez la taille des périphériques ou du tampon à l'aide de la commande hadbm set, le système de gestion vérifie la disponibilité des ressources lors de la création des bases de données ou de l'ajout de nœuds. Cependant, il ne vérifie pas si un nombre suffisant de ressources est disponible lors de la modification de la taille des périphériques ou du tampon de la mémoire principale. Solution Vérifiez qu'il y a suffisamment d'espace disque ou de mémoire disponible sur tous les hôtes avant d'augmenter les attributs de configuration devicesize ou buffersize. |
|||
5091349 |
Les chemins hétérogènes pour packagepath ne sont pas pris en charge. Il est impossible d'enregistrer le même package avec le même nom à différents emplacements et sur différents hôtes ; par exemple :
Solution La base de données HADB ne prend pas en charge les chemins hétérogènes sur plusieurs nœuds d'un cluster de base de données. Assurez-vous que le répertoire d'installation du serveur HADB (--packagepath) est le même pour tous les hôtes concernés. |
|||
6173886, 6253132 |
La commande createdomain peut échouer. Si l'agent de gestion est exécuté sur un hôte avec plusieurs interfaces réseau, la commande createdomain risque d'échouer si toutes les interfaces réseau ne se trouvent pas sur le même sous-réseau :
S'ils ne sont pas configurés autrement, les agents de gestion utilisent la première interface pour les multidiffusions UDP (la "première" étant déterminée par le résultat de java.net.NetworkInterface.getNetworkInterfaces() ). Solution La meilleure solution consiste à indiquer à l'agent de gestion quel sous-réseau utiliser (en définissant ma.server.mainternal.interfaces dans le fichier de configuration, par exemple ma.server.mainternal.interfaces=10.11.100.0). Une autre solution consiste à configurer le routeur entre les sous-réseaux de manière à acheminer les paquets multidiffusions. (L'agent de gestion utilise l'adresse multidiffusion 228.8.8.8.) Avant de réessayer avec une nouvelle configuration des agents de gestion, vous devrez peut-être nettoyer le référentiel des agents de gestion. Arrêtez tous les agents dans le domaine et supprimez tous les fichiers et répertoires du répertoire du référentiel (identifié par repository.dr.path dans le fichier de configuration des agents de gestion). Cette opération doit être effectuée sur tous les hôtes avant de redémarrer les agents avec le nouveau fichier de configuration. |
|||
6190878 |
Les répertoires doivent être nettoyés après la suppression d'une instance HADB. Après la suppression d'une instance HADB, les tentatives ultérieures de création de nouvelles instances à l'aide de la commande configure-ha-cluster échouent. Le problème est tel que les anciens répertoires de l'instance HADB d'origine sont conservés dans ha_install_dir/rep/* et dans ha_install_dir/config/hadb/instance_name . Solution Veillez à supprimer manuellement ces répertoires après la suppression d'une instance HADB. |
|||
6230792, 6230415 |
Le démarrage, l'arrêt ou la reconfiguration de HADB risque d'échouer ou de se bloquer. Sous Solaris 10 Opteron, le démarrage, l'arrêt ou la reconfiguration de HADB à l'aide de la commande hadbm risque d'échouer ou de se bloquer, en générant l'une des erreurs suivantes :
Cette erreur peut se produire s'il existe des incohérences lors de l'écriture ou de la lecture d'un fichier nomandevice) utilisé par le processus clu_noman_srv. Vous pouvez détecter ce problème en recherchant l'un des messages suivants dans les fichiers de l'historique de HADB :
Solution La solution suivante n'a pas été vérifiée, car le problème n'a pas été reproduit manuellement. Cependant, l'exécution de cette commande pour le nœud affecté devrait résoudre le problème.
Notez que tous les périphériques associés au nœud seront réinitialisés. Vous devrez peut-être arrêter le nœud avant de le réinitialiser. |
|||
6232140 |
L'agent de gestion s'arrête avec l'exception "IPV6_MULTICAST_IF failed". Si vous démarrez l'agent de gestion sur un hôte exécutant Solaris 8 et sur lequel plusieurs cartes réseau sont installées et que IPv6 et IPv4 sont activés simultanément, l'agent de gestion s'arrête et génère l'exception "IPV6_MULTICAST_IF failed"." Solution Paramétrez la variable d'environnement JAVA_OPTIONS sur -Djava.net.preferIPv4Stack=true ; par exemple :
Une autre solution consiste à utiliser Solaris 9 ou ultérieur, qui ne présente pas ce problème. |
|||
6249685 |
Le processus clu_trans_srv ne peut pas être interrompu. Il existe un bogue dans la version 64 bits de Red Hat Enterprise Linux 3.0 selon lequel le processus clu_trans_srv passe en mode non interruptible dans le cadre d'une E/S asynchrone. Cela signifie que la commande kill -9 ne fonctionne pas et que le système d'exploitation doit être réinitialisé. Solution Utilisez la version 32 bits de Red Hat Enterprise Linux 3.0. |
|||
6262824 |
La commande hadbm ne prend pas en charge les mots de passe contenant des lettres en majuscules. Les lettres en majuscules sont converties en minuscules lorsqu'un mot de passe est stocké dans hadb. Solution N'utilisez pas de mots de passe contenant des lettres en majuscules. |
|||
6265419 |
Une mise à niveau inférieur de HADB version 4.4.2.5 vers HADB version 4.4.1.7 entraîne l'échec de la commande ma avec différents codes d'erreur. Lors d'une mise à niveau inférieur d'une version HADB, l'agent de gestion peut échouer avec différents codes d'erreur. Solution Il est possible de mettre la base de données HADB à un niveau inférieur, mais ce n'est pas le cas pour l'agent de gestion si des modifications ont été apportées à des objets du référentiel. Une fois la mise à niveau inférieur effectuée, vous devez continuer à utiliser l'agent de gestion provenant de la version HADB la plus récente. |
|||
6271063 |
Conservation du lien symbolique symlink en cas d'installation/de suppression. Lors de l'installation/de la suppression du package c HADB (Solaris : SUNWhadbc, Linux : sun-hadb-c) version <m.n.u-p>, le lien symbolique symlink /opt/SUNWhadb/<m> existant n'est jamais affecté. Il est donc possible qu'un lien symbolique orphelin symlink existe. Solution Supprimez le lien symbolique symlink avant l'installation ou après la désinstallation, sauf s'il est en cours d'utilisation. |
|||
6273681 |
Il peut y avoir interaction entre les agents de gestion situés dans les zones globales et locales. Sous Solaris 10, l'arrêt d'un agent de gestion par le biais du script ma-initd dans une zone globale provoque également l'arrêt de l'agent de gestion de la zone locale. Solution N'installez l'agent de gestion que dans une de ces zones. |
|||
6275103 |
La commande hadbm/ma doit renvoyer un message d'erreur plus clair lors de l'expiration d'une session et de sa suppression au niveau de l'agent de gestion. Il peut arriver qu'un problème de conflit d'utilisation des ressources sur un serveur entraîne la déconnexion d'un client de gestion. Lors de la reconnexion, un message d'erreur trompeur, "hadbm:Error 22184: A password is required to connect to the management agent", peut être renvoyé. Solution Vérifiez s'il y a un problème de ressources sur le serveur, prenez les mesures nécessaires (par exemple, ajoutez des ressources) et relancez l'opération. |
|||
6275319 |
Les utilisateurs non root ne peuvent pas gérer la base de données HADB. Une installation par le biais de Java Enterprise System (en tant que root) ne permet pas aux utilisateurs non root de gérer la base de données HADB. Solution Connectez-vous toujours en tant que root pour pouvoir gérer la base de données HADB. |
|||
6293912 |
L'agent de gestion ne doit pas utiliser d'interfaces spécialisées. Les interfaces spécialisées portant des adresses IP comme 0.0.0.0 ne doivent pas être enregistrées comme des interfaces pouvant être utilisées pour des nœuds HADB dans l'agent de gestion. L'enregistrement de telles interfaces peut entraîner des problèmes si des nœuds HADB sont définis sur ces interfaces via une commande utilisateur hadbm create utilisant des noms d'hôtes à la place d'adresses IP. Les nœuds ne pourront plus communiquer, interrompant ainsi la commande create. Solution Lorsque vous utilisez hadbm create sur des hôtes à plusieurs interfaces, spécifiez toujours les adresses IP à l'aide d'une notation DDN. |
|||
6291562 |
Défaillances de réassemblage sous Windows. Sous Windows, avec certaines configurations et charges, un grand nombre d'échecs de réassemblage peut se produire dans le système d'exploitation. Le problème a été observé avec des configurations de plusieurs vingtaines de nœuds lors de l'exécution de plusieurs analyses parallèles de tables (select *). Les signes peuvent être tels que les transactions sont fréquemment abandonnées, la réparation ou la récupération peut prendre du temps et des délais d'expiration fréquents peuvent se produire dans différentes parties du système. Solution Pour résoudre le problème, la variable du registre Windows HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters peut être définie sur une valeur supérieure à celle par défaut de 100. Il est recommandé d'augmenter cette valeur à 0x1000 ( 4096). Pour plus d'informations, consultez l' article 811003 sur les pages de support Microsoft. |
|||
6303581, 6346059, 6307497 |
Lorsque la commande hadbm start <db_name> est exécutée, une partie de mot du passe saisi s'affiche. Il est possible, lorsqu'une machine est en sous-charge, que le mécanisme de masquage échoue et que certains caractères du mot de passe entré soient affichés. Ceci pose un problème mineur de sécurité et le mot de passe doit toujours être masqué. Solution Entrez les mots de passe dans les fichiers correspondants (méthode généralement recommandée depuis la version serveur d'application 8.1) et reportez-vous y avec l'option --adminpassword ou --dbpasswordfile. |
Cette section décrit les problèmes connus liés à l'installation et les solutions associées.
ID du bogue |
Résumé |
||
---|---|---|---|
5009728 |
Blocage lors de l'arrêt de l'installation sur certains systèmes Linux après avoir cliqué sur le bouton "Terminer". Ce problème se produit sur plusieurs systèmes Linux. Il apparaît le plus souvent sur Java Desktop System 2, mais il a également été observé sur les distributions Linux Red Hat. Lorsque vous cliquez sur le bouton Terminer du dernier écran, le programme d'installation ne parvient pas à ouvrir de fenêtre de navigation dans laquelle est affichée la page À propos de ou celle concernant l'enregistrement du produit. Il se bloque alors pour une période indéterminée, sans renvoyer d'invite de commande. Solution Quittez le programme d'installation en appuyant sur les touches Ctrl+C dans la fenêtre du terminal dans laquelle le programme d'installation a été démarré. Ceci devrait lancer l'affichage de la page À propos de ou de la page concernant l'enregistrement du produit dans la fenêtre du navigateur. Si ce n'est pas le cas, lancez le navigateur et saisissez l'URL suivant afin de vérifier la page À propos de :
Si vous avez également sélectionné l'option d'enregistrement du produit lors de l'installation, suivez le lien vers la page d'enregistrement disponible sur la page À propos de. |
||
6199697 |
Sous Windows, le répertoire imq doit être créé lors de l'installation. Sous Windows, dès qu'Application Server Enterprise Edition est installé, le courtier Message Queue échoue au démarrage et un message indiquant que le répertoire drive:\as\domains\domain1\imq n'existe pas apparaît. Notez que le problème ne se produit pas si le courtier est démarré après domain1, car le répertoire est créé par Application Server. Solution
|
||
6297837 |
Le programme d'installation de serveur d'application affiche la date incorrecte de mise sur le marché du produit dans le nom du produit, "Sun Java(TM) System Application Server Enterprise Edition 8.1 2005Q4." Solution La date ou le nom approprié du produit est le suivant "Sun Java(TM) System Application Server Enterprise Edition 8.1 2005Q2." |
||
6396045 |
serveur d'application ne prend pas en charge Network File System (NFS). Solution aucune. |
Pour exécuter le didacticiel J2EE 1.4 sur Sun Java System serveur d'application Environment Enterprise 8.1 2005Q2, effectuez les tâches suivantes :
Lorsque vous modifiez les exemples de fichier /common/build.properties, tel qu'indiqué dans la section “À propos des exemples” du chapitre “À propos de ce didacticiel”, remplacez le numéro de port 4848 par 4849.
Lorsque vous utilisez l'outil de déploiement (deploytool), indiquez localhost:4849 comme adresse de serveur avant de déployer un exemple.
Lorsque vous créez des ressources à l'aide de la console d'administration, utilisez l'onglet Cibles pour indiquer que le serveur est la cible. Si vous utilisez la ligne de commande ou une cible asant, le serveur représente la cible par défaut et aucune autre action n'est requise.
Cette section décrit les problèmes connus de gestion du cycle de vie et les solutions associées.
ID du bogue |
Résumé |
||
---|---|---|---|
6193449 |
Après avoir défini l'intervalle minimum-delivery-interval de la propriété ejb-timer-service sur 9000, la tentative pour définir l'intervalle redelivery-interval-in-mills de la propriété ejb-timer-service sur 7000 entraîne l'échec de la commande set avec l'erreur ci-dessous :
La relation entre la propriété de l'intervalle de redistribution et celle de l'intervalle de livraison minimal n'étant pas logique, il vous est impossible d'utiliser l'interface graphique (IG) ou l'interface de ligne de commande (CLI) pour définir un intervalle de livraison minimal supérieur à celui de redistribution. minimum-delivery-interval-in-millis doit toujours être égal ou supérieur à redelivery-interval-in-millis pour la propriété ejb-timer-service. Cependant, un contrôle de validité erroné s'effectue dans Application Server pour vérifier que la valeur de redelivery-interval-in-millis est supérieure à la valeur de minimum-delivery-interval-in-millis. Solution Utilisez les valeurs par défaut suivantes :
Toute autre valeur provoquera une erreur. |
Cette section décrit les problèmes connus de consignation et les solutions.
ID du bogue |
Résumé |
|
---|---|---|
6180095 |
Le paramétrage d'une instruction de débogage pour access,failure entraîne un blocage au démarrage d'Application Server. Le paramétrage de l'option java.security.debug pour JVM entraîne un blocage du démarrage de l'instance du serveur. Ce problème apparaît, par exemple, lorsque vous définissez les paramètres ci-dessous dans le fichier domain.xml :
Aucune pour l'instant. Évitez de paramétrer cet indicateur. |
Cette section décrit les problèmes connus liés aux files d'attente des messages Java et les solutions associées.
ID du bogue |
Résumé |
---|---|
6173308, 6189645, 6198481, 6199510, 6208728 |
Du fait de la synchronisation, la reconnexion JMS ne s'établit pas toujours correctement Dans des scénarios faisant appel à la synchronisation, plusieurs causes peuvent être à l'origine de ce problème. Solution Pour contourner ces problèmes :
|
6198465 |
Le comportement du listener de messages asynchrone a été modifié dans le conteneur appclient de la version 8.0 vers la version 8.1 Update 2. En raison d'une récente modification, lorsqu'un listener de messages asynchrone est le seul thread actif du conteneur app-client, l'autre machine virtuelle appclient existe en tant que démon. Ce comportement constitue une régression par rapport aux anciennes applications qui effectuent des réceptions asynchrones dans ACC. Ce problème affecte les clients d'application qui installent un listener de messages JMS et quittent le thread principal. Solution Ne fermez pas le thread principal. Attendez que le module d'écoute du message avertisse le thread principal avant de fermer ce dernier. |
Cette section décrit les problèmes connus liés au contrôle et les solutions associées.
ID du bogue |
Résumé |
||||||
---|---|---|---|---|---|---|---|
6174518 |
Certaines statistiques de contrôle du service HTTP ne contiennent aucune information utile et doivent être ignorées Des valeurs affichées dans les statistiques de contrôle de certains éléments du service HTTP ne correspondent pas aux valeurs actuelles ou sont égales à 0. Notamment les statistiques de service HTTP suivantes, car elles ne comportent pas d'informations applicables à Application Server et doivent donc être ignorées :
Solution Ces contrôles seront supprimés dans les versions ultérieures et remplacés par des informations mieux adaptées. |
||||||
6191092 |
Le contrôle de MBean pour un module EJB, dont le déploiement est annulé, n'est pas supprimé, même si toutes les statistiques regroupées sous ce nom de contrôle sont transférées. Par exemple :
Cela s'applique aux applications ainsi qu'aux modules EJB. Un mbean de contrôle vide existe même lorsque le contrôle est effectué par le programme (à l'aide de MBeanAPI) ou par les commandes asadmin list/get. Diagnostics
Vous pouvez consulter les statistiques:
Une fois le déploiement annulé:
Lorsque vous exécutez une commande de liste, l'application est toujours visible:
Mais aucune statistique de contrôle n'apparaît :
Pour obtenir les noms valides commençant par une chaîne, utilisez le caractère générique (*). Par exemple, pour établir une liste des noms de toutes les entités contrôlables qui commencent par server, indiquez list "server.*". Solution Ce problème est sans conséquence. Le module peut être redéployé en toute sécurité. Le Mbean de contrôle root n'est pas supprimé, mais il est vide. |
Cette section décrit les problèmes connus de PointBase et les solutions associées.
ID du bogue |
Résumé |
---|---|
6184797 |
Le paramétrage des niveaux d'isolement pour le pool de connexions d'une application génère des exceptions dans PointBase Pour un pool de connexions JDBC faisant référence à une installation de base de données PointBase, la définition de l'attribut de pool transaction-isolation-level sur une valeur différente de celle par défaut (Connection.TRANSACTION_READ_COMMITTED) génère une exception. En revanche, pour les pools associés à d'autres bases de données, aucune exception n'est générée lors de la définition de ce même attribut sur des valeurs autres que celles par défaut. Solution Ne définissez pas l'attribut transaction-isolation-level pour les pools de connexions JDBC faisant référence à une installation de base de données PointBase. |
6204925 |
PointBase génère une exception lorsqu'un serveur réseau est utilisé avec des pilotes imbriqués Il arrive que la base de données PointBase intégrée renvoie une exception lorsque le pilote du serveur réseau et le pilote imbriqué sont utilisés en même temps. Solution N'utilisez pas les deux pilotes simultanément. Choisissez soit le pilote imbriqué, soit le pilote du serveur réseau. |
6264969, 6275448 |
Problème de mise à niveau lorsque la base de données PointBase est écrasée. Lorsque vous effectuez une mise à jour vers serveur d'application Environment Enterprise 8.1 2005Q2 Update 2, le patch de mise à jour écrase la base de données par défaut PointBase. Solution Recréez ou entrez à nouveau tout schéma ou toute donnée existants avant la mise à niveau. Si vous avez déployé des applications avec des beans CMP à l'aide de l'option de génération de tables, vous devez annuler le déploiement ou redéployer l'application afin que les tables soient générées à nouveau. |
Cette section décrit les problèmes connus liés au code de l'exemple compris dans le produit serveur d'application 8.1 ainsi que les solutions associées.
ID du bogue |
Résumé |
|||||
---|---|---|---|---|---|---|
6195092 |
Sous Windows, la commande setup-one-machine-cluster reste bloquée tandis que sous Solaris, elle fonctionne correctement ; il faut appuyer sur Ctrl+C pour pouvoir annuler l'exécution de mqfailover, puis la relancer. En cas d'exécution des commandes suivantes dans install_dir\samples\ee-samples\failover\apps\mqfailover\docs\index.html, :
Si vous avez déjà exécuté asant setup-one-machine-cluster-without-ha ou asant setup-one-machine-cluster-with-ha pour un autre exemple Enterprise Edition, lancez asant configure-mq. Sinon, lancez asant setup-one-machine-cluster-and-configure-mq. La commande semble alors aboutir:
Néanmoins, le système se bloque pendant une période indéterminée. Solution Aucune pour l'instant. Ce problème touche de la même manière tous les exemples des produits Enterprise Edition qui utilisent cette cible ant sous Windows. Pour contourner ce problème, vous pouvez appuyer sur Ctrl+C afin de débloquer le processus avant de le relancer. |
|||||
6198003 |
La documentation ne signale pas, de façon explicite, que vous devez créer des ressources JMS avant d'exécuter l'exemple d'application de basculement MQ suivant les instructions de déploiement de asadmin. L'erreur générée est la suivante :
La documentation n'indique pas, de façon explicite, que des ressources JMS doivent être créées manuellement lorsque vous procédez au déploiement manuel à l'aide de la commande asadmin deploy, ni que vous devez utiliser les cibles ant fournies pour déployer l'exemple d'application. Solution Utilisez la cible asant deploy pour le script build.xml afin de créer les ressources JMS nécessaires à l'exécution de l'application. |
|||||
6198239 |
Erreur d'exécution lors de la création de certificats dans les exemples de sécurité/services Web sous Linux. Lors du déploiement de l'exemple install_dir/samples/webservices/security (basicSSl) sous Linux, le certificat 'est pas créé et une erreur similaire à celle présentée ci-dessous est générée :
Le problème est que les bibliothèques NSS ne se trouvent pas dans les mêmes emplacements sous Linux et Solaris. Lors du déploiement sous Linux, assurez-vous que le chemin LD_LIBRARY_PATH correspond à celui des bibliothèques NSS appropriées. Définissez la variable LD_LIBRARY_PATH dans votre environnement ou dans le script wrapper rép_install/bin/asant. Solution Effectuez l'une des opérations suivantes :
|
Cette section décrit les problèmes connus liés aux certificats et à la sécurité des applications Web sous serveur d'application ainsi que les solutions associées.
ID du bogue |
Résumé |
---|---|
6183318 |
Impossible d'exécuter les applications WebServiceSecurity sur Enterprise Edition avec J2SE 5.0. Les applications WebServiceSecurity ne peuvent être exécutées avec J2SE 5.0 pour les raisons suivantes :
Les membres de l'équipe J2SE ont inclus le message "CR 6190389: Add support for the RSA-PKCS1 and RSA-OAEP wrap/unwrap mechanisms" pour ce bogue. Solution Utilisez J2SE1.4.2 avec tout autre fournisseur JCE (autre que celui inclus par défaut). Retenez que cette configuration ne prend pas en charge l'accélération matérielle. |
6269102 |
La terminaison SSL ne fonctionne pas ; lorsque l'équilibreur de charge (matériel) est configuré pour la terminaison SSL, serveur d'application passe du protocole https à http au cours de la redirection. Solution Ajoutez un équilibreur de charge logiciel entre l'équilibreur de charge matériel et serveur d'application. |
Cette section décrit les problèmes connus de l'utilitaire de mise à niveau et les solutions associées.
ID du bogue |
Résumé |
||
---|---|---|---|
6165528 |
Les domaines créés dans un chemin personnalisé autre que le répertoire rép_install /domains ne sont pas directement mis à niveau lors de la mise à niveau d'Application Server Enterprise Edition 8 vers Application Server Enterprise Edition 8.1. Lors de l'exécution de l'utilitaire de mise à niveau et de l'identification de rép_install comme répertoire d'installation source, le processus de mise à niveau met uniquement à niveau les domaines créés sous le répertoire rép_install/domains. Les domaines créés à d’autres emplacements ne sont pas mis à niveau. Solution Avant de lancer le processus de mise à niveau, copiez tous les répertoires de domaines de leurs différents emplacements vers le répertoire rép_install/domains . |
||
6207337 |
Sur certains systèmes Linux, le programme d'installation effectuant la mise à niveau à son emplacement ne parvient pas à démarrer l'outil de mise à niveau après avoir cliqué sur le bouton Démarrer l'assistant de mise à niveau. Ce problème a été observé sur plusieurs systèmes Linux, en particulier sur Java Desktop System 2, mais également sur les distributions Red Hat. Après avoir cliqué sur le bouton Start Upgrade Tool (Démarrer l'outil de mise à niveau) qui se trouve sur l'écran final du programme d'installation, l'outil de mise à niveau n'est pas lancé et le programme d'installation se bloque pendant une période indéterminée, sans renvoyer d'invite de commande. Solution Ce problème ne survient pas lorsque le mode d'installation en ligne de commande est utilisé pour procéder à la mise à niveau à son emplacement.
Si vous avez également sélectionné l'option d'enregistrement du produit lors de l'installation, suivez le lien vers la page d'enregistrement disponible sur la page À propos de. |
||
6296105 |
Le certificat autosigné n'est pas approuvé au cours de et après la mise à niveau de 8.0 Platform Edition (PE) vers 8.1 Enterprise Edition (EE) UR2. Solution Supprimez les entrées suivantes de la cible domain.xml (après la mise à niveau) et redémarrez le serveur : <jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot} /config/keystore.jks</jvm-options>- <jvm-options>Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot} /config/cacerts.jks</jvm-options> |
Cette section décrit les problèmes connus liés au conteneur Web et les solutions associées.
ID du bogue |
Résumé |
|||
---|---|---|---|---|
5004315 |
Sous Windows, le déploiement d'une application à l'aide de la commande --precompilejsp=true peut verrouiller les fichiers JAR de l'application, entraînant l'échec des redéploiements et annulations de déploiement ultérieurs. Si vous devez effectuer une précompilation des pages JSP lors du déploiement d’une application sous Windows, les tentatives ultérieures de redéploiement ou d’annulation de déploiement de cette application (ou de toute autre application contenant le même ID de module) ne fonctionneront pas comme prévu. L’origine de ce problème provient du fait que la précompilation des pages JSP ouvre les fichiers JAR dans votre application, mais ne les referme pas. Windows empêche alors que le processus d’annulation du déploiement ne supprime ces fichiers ou que le processus de redéploiement ne les écrase. Il est à noter que l’annulation du déploiement réussit partiellement dans la mesure où l’application est supprimée d’Application Server. Notez aussi qu'aucun message d'erreur n'est retourné par l'utilitaire asadmin, mais que le répertoire de l'application et les fichiers jar verrouillés ne sont pas supprimés du serveur. Le fichier journal du serveur contient les messages décrivant l'échec de la suppression des fichiers et du répertoire de l'application. Toute tentative de redéploiement de l’application suite à l’annulation du déploiement échoue, car le serveur essaie en vain de supprimer le répertoire et les fichiers existants. Cela peut se produire si vous essayez de déployer une application qui utilise le même ID de module que celui de l'application initialement déployée. En effet, le serveur utilise cet ID de module lors de la sélection d'un répertoire destiné à contenir les fichiers de l'application. Les tentatives de redéploiement de l'application sans annulation préalable du déploiement échouent pour les mêmes raisons. Diagnostics Si vous essayez de redéployer l’application ou de la déployer après avoir annulé son déploiement, l’utilitaire asadmin renvoie une erreur similaire à l'erreur ci-dessous.
Solution Ce problème ne se produit pas si vous définissez le paramètre par défaut --precompilejsps=false lors du déploiement d’une application. Lors de sa première utilisation, l'application déclenche la compilation des pages JSP. C'est pour cette raison que le temps de réponse de la première requête est supérieur à celui des requêtes suivantes. Notez également qu’en cas de précompilation, vous devez arrêter et redémarrer le serveur avant d’annuler le déploiement de l’application ou de redéployer cette dernière. L’arrêt du serveur permet de libérer les fichiers JAR qui étaient verrouillés et d’effectuer correctement les opérations d’annulation du déploiement ou de redéploiement de l’application après le redémarrage. |
|||
6172006 |
Impossible de déployer les archives WAR avec le fichier web.xml basé sur le composant Servlet 2.4 comprenant un élément <load-on-startup> vide. L’élément facultatif load-on-startup inclus dans le fichier web.xml indique que le servlet correspondant doit être chargé et initialisé au démarrage de l'application Web à laquelle il appartient. Le contenu facultatif de cet élément est un nombre entier précisant en quelle position le servlet doit être chargé et initialisé par rapport aux autres servlets de l'application Web. Lorsque l'élément <load-on-startup> est vide, l'ordre de démarrage du servlet est inutile tant que celui-ci est chargé et initialisé au cours du démarrage de l'application Web dont il dépend. Le schéma Servlet 2.4 du fichier web.xml ne prend plus en charge les éléments <load-on-startup> vides, ce qui signifie que vous devez obligatoirement indiquer un nombre entier lorsque vous utilisez un fichier web.xml basé sur le composant Servlet 2.4. Si vous laissez l'élément <load-on-startup> vide, tel que <load-on-startup/>, le fichier web.xml ne parvient pas à valider le schéma Servlet 2.4 pour, provoquant l'échec du déploiement de l'application Web. Problème de compatibilité ascendante : Vous pouvez néanmoins laisser l'élément <load-on-startup> vide pour un fichier web.xml basé sur le composant Servlet 2.3. Solution Définissez la valeur <load-on-startup>0</load-on-startup> lors de l'utilisation d'un fichier web.xml basé sur Servlet 2.4 afin d'indiquer que l'ordre de chargement du servlet n'est pas important. |
|||
6184122 |
Impossible de compiler la page JSP sur des serveurs limités en ressources La page JSP est accessible mais ne peut pas être compilée. Le journal du serveur contient le message d’erreur "Impossible d'exécuter la commande" avec le suivi de pile suivant :
Solution Définissez le commutateur de compilation JSP fork sur false. Vous pouvez effectuer cette opération de l'une des deux manières suivantes:
Ces deux paramètres empêcheront ant de générer dynamiquement un nouveau processus pour la compilation javac. |
|||
6188932 |
Application Server ne prend pas en charge l'add-on auth-passthrough de Web Server 6.1. La fonction de plug-in auth-passthrough disponible dans Sun Java System serveur d'application Environment Enterprise 7.1 est prise en charge par Sun Java System serveur d'application Environment Enterprise 8.1 2005Q2 Update 2. Elle est cependant configurée différemment dans serveur d'application Environment Enterprise 8.1 2005Q2 Update 2. La fonction de plug-in auth-passthrough de serveur d'application Environment Enterprise 7.1 a été utilisée pour des scénarios de déploiement dans les architectures à deux niveaux où :
Dans de telles architectures réseau, un client se connecte à un serveur Web frontal préalablement configuré pour fonctionner avec la fonction de plug-in service-passthrough et transfère les requêtes HTTP à l'instance d' Application Server pour traitement via un proxy. Cette instance d'Application Server ne peut recevoir de requêtes que via le proxy du serveur Web mais ne peut pas en recevoir directement de la part d'hôtes clients. Par conséquent, toute application déployée sur l'instance d'Application Server qui envoie par proxy des requêtes pour obtenir des informations clientes (l'adresse IP du client par exemple) reçoit l'IP proxy de l'hôte par lequel la requête est relayée. Dans serveur d'application Environment Enterprise 7.1, la fonction de plug-in auth-passthrough peut être configurée sur l'instance d'Application Server utilisant un proxy afin de rendre directement disponibles les informations de clients distants pour n'importe quelle application déployée sur le serveur d'applications. Tout se passe alors comme si l'instance d'Application Server recevait la requête directement au lieu de la recevoir par l'intermédiaire d'un serveur Web exécutant le plug-in service-passthrough. Dans serveur d'application Environment Enterprise 8.1 2005Q2 Update 2, la fonctionnalité auth-passthrough peut être activée en définissant la propriété authPassthroughEnabled de l'élément <http-service> du fichier domain.xml sur TRUE comme suit :
|
|||
|
Les dispositions de sécurité concernant la fonction de plug-in auth-passthrough de serveur d'application Environment Enterprise 7.1 s'appliquent de la même manière à la propriété authPassthroughEnabled dans serveur d'application Environment Enterprise 8.1 2005Q2 Update 2. La propriété authPassthroughEnabled permettant d'ignorer des informations qui peuvent être utilisées à des fins d'authentification (adresse IP depuis laquelle la requête d'origine a été émise, certificat SSL du client, etc.), il est impératif de faire en sorte que seuls des clients ou des serveurs de confiance soient autorisés à se connecter à une instance serveur d'application Environment Enterprise 8.1 2005Q2 Update 2 en ayant défini la propriété authPassthroughEnabled sur TRUE. Par mesure de précaution, il est recommandé de ne définir la propriété authPassthroughEnabled sur TRUE que pour des serveurs protégés par le pare-feu d'entreprise. Pour un serveur accessible par Internet, la propriété authPassthroughEnabled ne doit jamais être définie sur TRUE. Il est à noter que dans le cas où le plug-in service-passthrough a été configuré sur un serveur Web proxy qui relaie les requêtes vers une instance d'Application Server 8.1 Update 2 pour laquelle la propriété authPassthroughEnabled a été définie sur TRUE, l'authentification cliente SSL peut être activée sur le proxy du serveur Web et désactivée sur celui de l'instance d'Application Server 8.1 Update 2. Dans ce cas, l'instance d'Application Server 8.1 Update 2 utilisant un proxy continue de traiter les requêtes comme si elles étaient authentifiées via SSL et fournit un certificat SSL client aux applications déployées lorsque nécessaire. |