En este capítulo se describen los problemas conocidos y las soluciones asociadas para el software de Sun Java System Application Server Edición Enterprise 8.2. Si no se especifica una plataforma concreta para un problema, significa que éste se aplica a todas las plataformas. Esta información se ha dividido como sigue:
Este apartado describe problemas conocidos relacionados con la administración, junto con las soluciones pertinentes.
De forma predeterminada, hay un valor codificado en $INSTALL/lib/package-appclient.xml para la variable AS_ACC_CONFIG de domain1 a la que señala asenv.conf. Si domain1 se elimina y se crea un nuevo dominio, la variable AS_ACC_CONFIG no se actualiza con el nombre del dominio nuevo, lo que provoca que falle la secuencia de comandos package-appclient .
Lleve a cabo una de las siguientes acciones:
Deje intacto domain1 y cree los demás dominios en torno a él.
Elimine domain1 y sustituya el valor codificado de domain1 en $INSTALL/lib/package-appclient.xml por el nuevo nombre de dominio. Deberá llevar a cabo este procedimiento cada vez que cree un dominio nuevo si domain1 no está presente.
Si instala el complemento de equilibrado de carga en una instalación de Application Server que ya tiene un complemento de equilibrador de carga instalado (por ejemplo, de 7.1EE), entonces el complemento de 8.2EE reemplazará cualquier equilibrador de carga existente, incluso si ha creado una nueva instancia de servidor en la que ejecutará el complemento.
Los archivos de complemento se instalan de forma predeterminada en el directorio install_dir /plugins/lbplugin, lo que significa que sólo se puede utilizar una versión de un complemento con una instalación de Application Server. Tenga en cuenta que el programa de instalación de la consola muestra un mensaje que indica que se está realizando una desinstalación, pero este mensaje a veces puede ser fácil de pasar por alto.
No todo el mundo se encontrará con este problema. Si surge este problema, elimine la instalación antigua de Application Server e instale una nueva en lugar de realizar una instalación mediante actualización.
Se han realizado varios cambios en el comando asadmin en Application Server 8.2 en comparación con Application Server 7.x. Por ejemplo, en 7.x, el comando que inicia una instancia de servidor es:
asadmin start-instance |
En 8.2, el comando equivalente es:
asadmin start-domain --user admin domain1 |
Consulte los siguientes documentos para obtener información completa sobre la última sintaxis del comando asadmin:
Sun Java System Application Server Enterprise Edition 8.2 Administration Guide
Sun Java System Application Server Enterprise Edition 8.2 Reference Manual
Sun Java System Application Server Enterprise Edition 8.2 Upgrade and Migration Guide
Al actualizar a JES5/Application Server 8.2 de JES2/Application Server 7. x, puede que experimente incompatibilidades o errores debido a que se han cambiado los puertos predeterminados.
Consulte Otros requisitos al comienzo de estas notas para ver una lista de los puertos predeterminados utilizados en Application Server 8.2.
No se puede realizar la duplicación de un dominio en la misma instalación de Application Server mediante los comandos backup-domain y restore-domain , ya que el dominio no se puede restaurar con un nombre distinto del original, aunque el comando asadmin restore-domain proporcione una opción para cambiar el nombre del dominio. Parece que el cambio de nombre del dominio del que se ha hecho una copia de seguridad es correcto, pero al intentar iniciar el dominio en cuestión se producen errores porque las entradas de la configuración del dominio no se han cambiado, y startserv y stopserv usan el nombre de dominio original para definir las rutas.
El nombre de dominio utilizado para restore-domain debe ser el mismo que se usó para el comando original backup-domain. Los comandos backup-domain y restore-domain de Application Server 8.2 sólo se pueden utilizar para realizar copias de seguridad y restaurar el mismo dominio en el mismo equipo.
J2SE 1.4.x, 5.0 o superior puede configurarse en Application Server. Una función integral de la plataforma J2SE 5.0 es la capacidad para iniciar un agente JMX. Esta función se activa definiendo explícitamente propiedades de sistema al iniciar el servidor.
Entre los valores de ejemplo se incluyen:
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"
Después de configurar las propiedades de JMX e iniciar el servidor, se inicia un nuevo jmx-connector en Application Server VM. Un efecto secundario no deseable es que las funciones de administración se ven afectadas negativamente, y la CLI y la GUI de administración de Application Server pueden generar resultados inesperados. El problema es que se producen algunos conflictos entre el servidor integrado jmx-connector y el nuevo servidor jmx-connector.
Si utiliza jconsole (o cualquier otro cliente compatible con JMX), puede reutilizar el servidor estándar JMX Connector Server que se ejecuta al iniciar Application Server.
Al iniciar el servidor, se muestra una línea parecida a la que aparece más abajo en el registro del servidor. Puede conectarse a la JMXServiceURL especificada en dicha ubicación y realizar las mismas operaciones de configuración y administración después de que se proporcionen correctamente las credenciales, por ejemplo:
[#|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.|#]
Para obtener más información, consulte la Guía de administración de Sun Java System Application Server 8.2.
Si ejecuta el comando asadmin restore-domain cuando haya iniciado una sesión como usuario "A", las secuencias de comandos se finalizarán con permisos 744 (rwxr--r--
). Si, posteriormente, intenta iniciar o detener un dominio utilizando el usuario "B" (incluso aunque "B" sea root), se producirá un error, ya que las secuencias de comandos sólo podrán ser ejecutadas por el usuario "A".
Cambie los permisos de las secuencias de comandos:
chmod 755 appserv/domains/domain-name/bin/* |
Al configurar el equilibrador de carga con una aplicación que tenga un módulo EJB que exporte una URL de servicio web, la raíz del contexto para el nuevo servicio web no se encuentra en el archivo loadbalancer.xml resultante.
Edite el archivo loadbalancer.xml para agregar los módulos web que falten de la siguiente forma:
<web-module context-root="context-root-name" disable-timeout-in-minutes="30" enabled="true"/> |
Sustituya el valor de context-root-name con el nombre root del contexto del servicio web que se expuso como EJB.
Los dominios o servidores de Application Server no utilizan el JDK al que señala el atributo java-home del elemento java-config de la configuración asociada.
El JDK utilizado por los procesos de Application Server de todos los dominios en una instalación del servidor específica viene determinado por el archivo appserver-installation-dir /config/asenv.conf. La propiedad AS_JAVA de este archivo determina el JDK que se utilizará y establecerá durante la instalación. Si los procesos de Application Server utilizan un JDK diferente una vez completada la instalación, este valor puede modificarse para que señale a otro JDK. Tenga en cuenta que este cambio afectará a todos los dominios de esta instalación.
Al realizar cambios en el archivo asenv.conf, debe tener cuidado, ya que no se comprueba su validez. Consulte la documentación del producto para conocer los requisitos mínimos de la versión de JDK al modificar el valor de AS_JAVA.
Este problema lo genera un valor erróneo de %CONFIG_HOME%.
Cambie el nombre del elemento existente a asant.bak.
Copie el archivo asant.template ubicado en <as_install> /lib/install/templates/ee (para la versión SE/EE version) en el directorio <as_install>/bin/ y cambie el nombre del archivo asant.
Edite la secuencia de comandos <as_install> /bin/asant que acaba de copiar sustituyendo el token %CONFIG_HOME% por <as_install>/config.
Si se ha efectuado algún cambio manual en el archivo asant.bak original, combínelo con la nueva secuencia de comandos asant.
Si el archivo no se encuentra en el directorio home del administrador del servidor, es posible que se produzcan errores graves al actualizar determinadas aplicaciones alojadas en el servidor.
Si el posible, el usuario que instaló el servidor debería ejecutar el comando asadmin start-domain domain1.
Si, por el contrario, no es posible, .asadmintruststore debería moverse o copiarse del directorio home del usuario que ha efectuado la instalación al directorio home del usuario que está ejecutando el servidor.
Tenga en cuenta que si se mueve (no se copia) el archivo del directorio home del usuario de instalación al directorio home del usuario de ejecución, es posible que se produzcan problemas con la actualización de la aplicación, como se describe en los errores 6309079, 6310428 y 6312869, ya que el usuario de instalación/actualización (normalmente root en Java ES) ya no dispondrá del archivo .asadminstruststore en su directorio principal.
El dominio no se inicia cuando la contraseña maestra del dominio contiene el carácter de porcentaje (%).
La contraseña maestra del dominio no debe contener un carácter de porcentaje (%). Esta limitación es aplicable al crear un nuevo dominio o cambiar la contraseña maestra del dominio existente.
Después de crear un archivo http-listener seguro e instalar lbplugin, los archivos magnus.conf y obj.conf en webserver_instance_dir/config se modifican y el contenido de lbplugin se elimina.
El programa de instalación modifica los archivos de configuración magnus.conf y obj.conf de Application Server como parte de la instalación del complemento de equilibrador de carga. Si inicia una sesión en la consola de administración de Application Server e intenta administrar la configuración de instancias para la instancia en la que el equilibrador de carga se ha instalado, Application Server muestra un mensaje de advertencia en el que se indica que han detectado modificaciones manuales en la configuración. Esta advertencia, en realidad, hace referencia a los cambios que ha realizado el programa de instalación.
Compruebe que los cambios realizados por el programa de instalación no se han sobrescrito.
En este apartado se describen los problemas conocidos relacionados con el complemento del equilibrador de carga y Apache Web Server, y las soluciones pertinentes.
Cuando compile y cree openssl, ejecute los siguientes comandos:
cd openssl-0.9.7e config make |
Además, para Apache 1.3, el nombre del directorio del origen mod_ssl variará en función de la versión de Apache que se use. Por ejemplo, para Apache 1.3.33, el nombre es mod_ssl-2.8.22-1.3.33.
Para ejecutar la seguridad de Apache, debe usar un certificado. Para conocer cómo se obtiene un certificado de una entidad emisora de certificados, consulte la información sobre los certificados que figura en modssl FAQ.
En Solaris, si Application Server se instaló como root, deberá usar Apache Web Server también como root. Las instalaciones de Java Enterprise System se realizan como root. En Apache 2.0, después de iniciarse como root, Apache cambia y se ejecuta como el usuario que se especifique. Especifique ese usuario en el archivo /conf/httpd.conf. Para realizar un inicio como root en varios sistemas, debe editar el archivo httpd.conf para especificar el grupo correcto. Sustituya la línea:
Group #-1 |
por
Group nobody |
Encontrará más información sobre el uso de user/group en el archivo httpd.conf.
Después de instalar Apache 2.0 y el complemento del equilibrador de carga, edite ssl.conf and sll-std.conf de la siguiente forma:
Sustituya la línea:
<VirtualHost _default_:9191>
por
<VirtualHost machine_name:9191>
donde machine_name es el nombre de su equipo y 9191 es el número del puerto de seguridad.
Este apartado describe problemas conocidos relacionados con los clientes de la aplicación, junto con las soluciones pertinentes.
Si cuenta con un archivo JAR de nivel superior en el cliente JAR (en este caso, reporter.jar), cuando implemente el cliente JAR, el archivo MANIFEST de dicho JAR sobrescribirá el archivo MANIFEST del cliente JAR.
Ninguna por ahora.
Ya no se admiten las tecnologías de contenido dinámico como, por ejemplo, CGI-bin y SHTML.
En su lugar, utilice las tecnologías de servicios web y JSP.
Este apartado describe problemas conocidos relacionados con los controladores JDBC de Sun, junto con las soluciones pertinentes.
Para definir el nivel deseado de aislamiento para una conexión, el conjunto de conexiones correspondiente debe crearse en el mismo nivel de aislamiento. Consulte Sun Java System Application Server Enterprise Edition 8.2 Administration Guide para obtener más información sobre la configuración de conjuntos de conexión.
Si una aplicación genera más de 3000 objetos PreparedStatement en una transacción, se puede producir el siguiente error con DB2:
[sunm][DB2 JDBC Driver] No more available statements.. Please recreate your package with a larger dynamicSections value.
Agregue las siguientes propiedades a la definición del conjunto de conexiones para que el controlador vuelva a vincular los paquetes DB2 con un valor mayor de secciones dinámicas:
createDefaultPackage=true replacePackage=true dynamicSections=1000
Consulte Sun Java System Application Server Enterprise Edition 8.2 Administration Guide para más información sobre la configuración de conjuntos de conexión.
En relación con el error de PrepardStatement mencionado anteriormente, otro mensaje de error que se puede mostrar es:
[sunm][DB2 JDBC Driver][DB2]Virtual storage or database resource is not available.
Aumente el parámetro de configuración APPLHEAPSZ del servidor DB2 Un valor adecuado es 4096.
Nivel de aislamiento TRANSACTION_SERIALIZABLE. Si una aplicación utiliza un nivel de aislamiento TRANSACTION_SERIALIZABLE y emplea uno de los parámetros sugeridos anteriormente, es posible que se bloquee cuando intente obtener la conexión.
Para definir el nivel deseado de aislamiento para una conexión, el conjunto de conexiones correspondiente debe crearse en el mismo nivel de aislamiento. Consulte Sun Java System Application Server Enterprise Edition 8.2 Administration Guide para obtener instrucciones.
Es posible que se bloqueen las aplicaciones que utilizan el nivel de aislamiento TRANSACTION_SERIALIZABLE con el controlador de Sun integrado para Sybase Adaptive Server cuando se utiliza una instrucción preparada para actualizar, en caso de que se estén llevando a cabo dos transacciones paralelas y una de ellas se deshaga. El proceso para deshacer la conexión falla y se muestra el siguiente mensaje. Las conexiones deshechas no se pueden utilizar nunca más:
java.sql.SQLException: [sunm][Sybase JDBC Driver]Request cannot be submitted due to wire contention
Sybase Adaptive Server no es compatible con el nivel de aislamiento TRANSACTION_REPEATABLE_READ . No obstante, al realizar una consulta en DatabaseMetaData, el controlador integrado de Sun indica que dicho nivel de aislamiento sí es compatible con la base de datos. Las aplicaciones que utilizan este nivel de aislamiento fallarán.
Las aplicaciones que usan el controlador integrado de Sun no pueden establecer el nivel de aislamiento TRANSACTION_READ_UNCOMMITTED. La aplicación desencadena la siguiente excepción en el primer acceso de DataBaseMetaData:
java.sql.SQLException: [sunm][Sybase JDBC Driver][Sybase]The optimizer could not find a unique index which it could use to perform an isolation level 0 scan on table 'sybsystemprocs.dbo.spt_server_info'.
Ninguna por ahora.
Defina la siguiente propiedad en el conjunto de conexiones de JDBC cuando use el origen de datos de Oracle SUN JDBC (com.sun.sql.jdbcx.oracle.OracleDataSource):
<property name="serverType" value="dedicated"/>
El valor de la propiedad depende del modo en que esté configurado el módulo de escucha del servidor Oracle. Si está configurado en el modo "compartido", el valor anterior deberá cambiarse a "dedicated".
Comience con controladores JDBC 10.2, si tiene más de un archivo jar JDBC en CLASSPATH puede que resulte en java.lang.SecurityException: Sealing violation exception.
Una explicación detallada de Oracle está documentada en el siguiente ID de Documento Oracle:
Note:405446.1 Subject: JDBC Driver 10.2 Uses Sealed JAR files and May Cause SecurityException Sealing Violation
(Suggested by Oracle) Make sure that the CLASSPATH includes only one JDBC driver JAR file.
En este apartado se describen los problemas conocidos relacionados con la arquitectura del conector J2EE y las soluciones asociadas.
En esta situación, un módulo de conector independiente o integrado está implementado en DAS y los conjuntos de conexiones del conector y los recursos se crean para el módulo implementado. Después de reiniciar la instancia DAS, la anulación de la implementación del módulo del conector falla cuando la cascada se establece como false con la siguiente excepción:
[#|2004-10-31T19:52:23.049-0800|INFO|sun-appserver-ee8.1|javax.enterprise.system .core|_ThreadID=14;|CORE5023: Error while unloading application [foo]|#].
Use la anulación de implementación en cascada (establezca la opción cascade en true) para anular la implementación de los conectores integrados e independientes después de reiniciar la instancia DAS.
Como no puede especificar los tamaños mínimo y máximo del conjunto al crear un nuevo recurso JMS desde la línea de comandos con el comando asadmin create-jms-resource, se supone que el comando asadmin crea el recurso utilizando los valores de tamaño del conjunto predeterminados (mínimo 8, máximo 32). Sin embargo, éste no es el caso. En su lugar, la creación del recurso desde la línea de comandos da como resultado los tamaños de conjunto mínimo y máximo predeterminados, 1 y 250 respectivamente.
Una vez creado un recurso JMS desde la línea de comandos, utilice la consola de administración para modificar los valores de tamaño de conjunto mínimo y máximo.
Este apartado describe problemas conocidos relacionados con la documentación, junto con las soluciones pertinentes.
Falta Javadoc o es incorrecto para varios métodos e interfaces AMX:
Los métodos Getter para las estadísticas NumConnAcquired y NumConnReleased no están incluidos en ConnectorConnectionPoolStats y AltJDBCConnectionPoolStats. Dichos métodos se agregarán en una próxima versión con los nombres getNumConnAcquired() y getNumConnReleased().
Si intenta ejecutar los siguientes métodos en EJBCacheStats, se desencadenará una excepción: getPassivationSuccesses(), getExpiredSessionsRemoved(), getPassivationErrors()y getPassivations(). Este error se solucionará en una futura versión.
AMX MBeans necesitan varios segundos después de que se inicie el servidor para registrarse y estar disponibles para su uso. En una versión futura será posible determinar si los AMX MBeans están totalmente cargados.
La constante XTypes.CONNNECTOR_CONNECTION_POOL_MONITOR está mal escrito ("NNN"). Este error se solucionará en una futura versión.
La siguiente excepción fue iniciada en subproceso main: java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher.
No se recomienda el uso del ANT integrado para cuestiones externas a Application Server.
La Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide indica incorrectamente lo siguiente a cerca de las opciones de registro:
La GUI de administración proporciona las siguientes dos opciones de registro:
Opción 1: contenido del registro stdout (System.out.print) en el registro de eventos.
Opción 2: contenido del registro stderr (System.err.print) en el registro de eventos.
Estas opciones de registro ya no están disponibles en Application Server Edición Enterprise 8.2.
La documentación de Application Server Edición Enterprise 8.2 describe una función de almacenamiento en caché de archivos HTTP en HTTP File Cache de Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide. Sin embargo, esta función no se ha incluido en Application Server Edición Enterprise 8.2. Tenga en cuenta que esta función se ha vuelto a introducir en Application Server 9.0.
A consecuencia de otros errores (posiblemente 6295215), el código proporcionado en la sección Obtaining a Physical Connection from a Wrapped Connection de Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide del Capítulo 11, Using the JDBC API for Database Access de Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide no es correcto. En concreto, la línea siguiente:
Connection drivercon = ds.getConnection(con); |
debería indicar:
Connection drivercon = ((com.sun.gjc.spi.DataSource)ds).getConnection(con); |
En este apartado se describen los problemas conocidos relacionados con la base de datos de alta disponibilidad (HADB) y las soluciones asociadas.
La configuración de HADB con redes dobles en dos subredes funciona correctamente en Solaris SPARC. Sin embargo, debido a problemas en el sistema operativo o a los controladores de red en algunas plataformas de hardware, se ha observado que las plataformas Linux y Solaris x86 no siempre gestionan correctamente las redes dobles. Esto provoca los siguientes problemas con HADB:
En Linux, algunos de los procesos de HADB se bloquean al enviar mensajes. Esto hace que el nodo de HADB se reinicie y se produzcan particiones en la red.
En Solaris x86, pueden surgir algunos problemas después de un fallo de red que impidan cambiar a otras interfaces de red. Esto no sucede siempre, por lo que sigue siendo mejor tener dos redes que una sola. Estos problemas se han resuelto parcialmente en Solaris 10.
No se admite el truncamiento.
HADB no admite el uso de redes dobles en Windows 2003 (ID 5103186).
La creación de una base de datos nueva puede fallar con el siguiente error, que indica que hay muy pocos segmentos de memoria compartida disponibles:
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.
Compruebe que la memoria compartida esté configurada y que la configuración esté funcionando. En concreto, en Solaris 8, consulte el /etc/system, y compruebe que el valor de la variable shmsys:shminfo_shmseg sea, como mínimo, 6 veces el número de nodos por host.
HADB 4.3-0.16 y posterior se configura para utilizar la memoria compartida privada al crearse y adjuntarse a sus segmentos de memoria compartida (utiliza el indicador SHM_SHARE_MMU ). El uso de este indicador básicamente bloquea los segmentos de memoria compartida en la memoria física e impide que se eliminen. Esto puede fácilmente provocar problemas con instalaciones en equipos finales lentos.
Por tanto, si un programador tiene un equipo con 512 MB de memoria y mucho espacio de intercambio disponible al utilizar Application Server7.0 EE y, a continuación, instala 7.1 EE o posterior, tendrá problemas al configurar el clúster predeterminado clsetup, que crea dos nodos HADB, cada uno con un tamaño, devicesize, de 512, que da lugar a que no haya suficiente RAM física para soportar la memoria compartida que ambos nodos necesitan.
Asegúrese de que dispone de la cantidad recomendada de memoria al ubicar de forma conjunta Application Server y HADB. Consulte Requisitos de HADB y plataformas compatibles para obtener más información.
Al aumentar el tamaño de la memoria búfer o de los dispositivos usando hadbm set,, el sistema de administración comprueba la disponibilidad de los recursos cuando se crean bases de datos o se agregan nodos, pero no comprueba si hay recursos suficientes cuando se cambia el tamaño de la memoria búfer principal o del dispositivo.
Compruebe si hay espacio de disco o de memoria suficiente en todos los hosts antes de aumentar los atributos de configuración devicesize o buffersize.
No se puede registrar el mismo paquete de software con el mismo nombre en ubicaciones distintas y en hosts diferentes, por ejemplo:
hadbm registerpackage test --packagepath=/var/install1 --hosts europa11 Package successfully registered. hadbm registerpackage test --packagepath=/var/install2 --hosts europa12 hadbm:Error 22171: A software package has already been registered with the package name test. |
HADB no admite rutas heterogéneas en los nodos de un clúster de base de datos. Asegúrese de que el directorio de instalación de HADB (--packagepath) sea el mismo para todos los hosts.
Si el agente de administración se está ejecutando en un host con varias interfaces de red, es posible que el comando create domain presente errores si no están todas las interfaces de red en la misma subred:
hadbm:Error 22020: The management agents could not establish a domain, please check that the hosts can communicate with UDP multicast. |
Los agentes de administración, a menos que estén configurados de otra forma, usarán la "primera" interfaz para difusiones UDP (se entiende como "primera" interfaz el resutado de java.net.NetworkInterface.getNetworkInterfaces()).
La mejor solución es indicarle al agente de administración qué subred debe utilizar (defina ma.server.mainternal.interfaces en el archivo de configuración, por ejemplo, ma.server.mainternal.interfaces=10.11.100.0). Otra opción es configurar el enrutador entre las subredes para que dirija los paquetes de difusión (el agente de administración utiliza la dirección de difusión 228.8.8.8).
Antes de volver a intentarlo con una configuración nueva de los agentes de administración, puede que deba limpiar el repositorio del agente de administración. Detenga todos los agentes del dominio, y elimine todos los archivos y directorios del directorio del repositorio (se identifican mediante repository.dr.path en el archivo de configuración del agente de administración). Esta acción debe realizarse en todos los hosts antes de reiniciar los agentes con un nuevo archivo de configuración.
Una vez eliminada una instancia de HADB, fallarán los intentos siguientes de crear nuevas instancias con el comando configure-ha-cluster. El problema es que los antiguos directorios permanecen en la instancia de HADB original en ha_install_dir/rep/* y ha_install_dir/config/hadb/instance_name .
Asegúrese de que elimina manualmente estos directorios tras eliminar una instancia de HADB.
En Solaris 10 Opteron, el inicio, la detención o la reconfiguración de HADB usando el comando hadbm pueden fallar o generar bloqueos con alguno de los siguientes errores:
hadbm:Error 22009: The command issued had no progress in the last 300 seconds. HADB-E-21070: The operation did not complete within the time limit, but has not been cancelled and may complete at a later time. |
Esto puede suceder si hay incoherencias al leer o escribir en un archivo (nomandevice) que esté utilizando el proceso clu_noman_srv. Este problema se puede detectar buscando los siguientes mensajes en los archivos del historial de HADB:
n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Child process noman3 733 does not respond. n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Have not heard from it in 104.537454 sec. n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Child process noman3 733 did not start. |
La siguiente solución no se ha probado, puesto que no se ha reproducido el problema manualmente. Sin embargo, la ejecución de este comando para el nodo afectado debería resolver el problema.
hadbm restartnode --level=clear nodeno dbname |
Tenga en cuenta que se reiniciarán todos los dispositivos del nodo. También es posible que haya que detener el nodo antes de reiniciarlo.
Cuando se inicia en un host que ejecuta Solaris 8 con varias tarjetas NIC instaladas, si hay una mezcla de tarjetas con IPv6 e IPv4 habilitados, el agente de administración puede terminar con la excepción "IPV6_MULTICAST_IF failed."."
Defina la variable de entorno JAVA_OPTIONS en -Djava.net.preferIPv4Stack=true como, por ejemplo:
export JAVA_OPTIONS="-Djava.net.preferIPv4Stack=true" |
De lo contrario, use Solaris 9 o una versión posterior que no esté afectada por este problema.
Hay un error en la versión de 64 bits de Red Hat Enterprise Linux 3.0 que hace que el proceso clu_trans_srv termine en modo sin interrupción cuando se realiza una E/S asíncrona. Esto significa que kill -9 no funciona y el sistema operativo debe reiniciarse.
Use una versión de 32 bits de Red Hat Enterprise Linux 3.0.
Las letras mayúsculas en las contraseñas se convierten en minúsculas cuando la contraseña se almacena en hadb.
No use contraseñas que contengan letras mayúsculas.
Al retroceder en las versiones, el agente de administración puede fallar con distintos códigos de error.
Es posible retroceder en la versión de la base de datos de HADB, sin embargo, el agente de administración no podrá retroceder en su versión si se han hecho cambios en los objetos del repositorio. Después de retroceder en la versión, deberá usar el agente de administración de la última versión de HADB.
Con respecto a la instalación o eliminación del paquete de HADB (Solaris: SUNWhadbc, Linux: sun-hadb-c) versión <m.n.u-p>, symlink /opt/SUNWhadb/<m> no se modifica una vez creado. En consecuencia, es posible que exista un symlink huérfano.
Elimine el symlink antes de la instalación o después de la desinstalación, a menos que esté en uso.
En Solaris 10, al detener el agente de administración usando la secuencia de comandos ma-initd en una zona global, se detiene también el agente de administración en la zona local.
No instale el agente de administración en la zona global y la local.
A veces un problema de contención de recursos en el servidor puede provocar la desconexión de un cliente de administración. Al volver a conectar, puede devolverse el siguiente mensaje de error confuso "hadbm:Error 22184: A password is required to connect to the management agent".
Compruebe si hay algún problema con los recursos en el servidor, realice las acciones necesarias (por ejemplo, agregue más recursos) y vuelva a intentar la operación.
La instalación de Java Enterprise System (como root) no permite que los usuarios que no sean root administren HADB.
Inicie sesión siempre como root para poder administrar HADB.
Las interfaces de uso especial con direcciones IP similares a 0.0.0.0 no deberían registrarse como interfaces válidas para los nodos de HADB en el agente de administración. El registro de dichas interfaces podría provocar problemas si los nodos de HADB se configuran en estas interfaces mediante la ejecución del comando hadbm create por parte del usuario con nombres de host en lugar de con direcciones IP. Los nodos no podrán establecer comunicación, lo que provocara el bloqueo del comando create.
Al utilizar hadbm create en hosts con varias interfaces, especifique siempre explícitamente las direcciones IP con una notación DDN.
En la plataforma Windows, con determinadas configuraciones y cargas, es posible que se produzca un gran número de errores de reensamblaje en el sistema operativo. Se ha detectado este problema con configuraciones de más de veinte nodos al ejecutar varios análisis de tabla (select *) en paralelo. Entre los síntomas detectados, se incluyen los siguientes: las transacciones se anulan frecuentemente, el proceso de reparación o recuperación tarda mucho tiempo en completarse, y se agota frecuentemente el tiempo de espera en diversas partes del sistema.
Para solucionar el problema, puede establecer la variable del registro de Windows HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters en un valor superior a 100 (valor predeterminado). Se recomienda que aumente este valor a 0x1000 ( 4096). Para obtener más información, consulte el artículo 811003 en las páginas de asistencia técnica de Microsoft.
Es posible que, cuando un equipo esté realizando una carga, el mecanismo de ocultación falle y se expongan algunos caracteres de la contraseña introducida. Esto representa un riesgo de seguridad menor y la contraseña debería estar siempre oculta.
Guarde las contraseñas en sus propios archivos de contraseñas (el método recomendado normalmente desde Application Server 8.1) y consúltelas con las opciones --adminpassword o --dbpasswordfile.
Cuando se instala Application Server en una zona global de Solaris en el directorio /usr/SUNWappserver , el componente HADB instalado con la instancia de Application Server no estará disponible en las zonas locales dispersas.
El problema es que HADB se instala en el directorio /opt/SUNWhadb de la zona global, pero este directorio no tiene acceso de lectura desde las zonas locales dispersas. Desafortunadamente, el HADB integrado en JES5 no se puede reubicar.
Como el componente HADB de Application Server no se puede reubicar, debe instalarse por separado en cada zona local dispersa desde la que desee acceder a HADB.
Este apartado describe problemas conocidos relacionados con la instalación, junto con las soluciones pertinentes.
Se ha observado que este problema se ha producido en varios sistemas Linux. Es más frecuente en Java Desktop System 2, pero también se ha observado en distribuciones Linux Red Hat.
Después de hacer clic en el botón Finalizar en la última pantalla, el programa de instalación no consigue iniciar una ventana del explorador que contiene la página con información acerca del producto o la página de registro. El programa de instalación se bloquea completamente y no permite volver a la línea de comandos.
Salga de instalador pulsando Ctrl+C en la ventana de terminal en la que se inició el instalador. Después de hacer esto, es posible que se muestre una ventana del explorador que contiene información acerca del producto o la pantalla de registro, de lo contrario, inicie el navegador y escriba la siguiente dirección URL para ver la información acerca del producto:
file://install_dir/docs-ee/about.html |
Si seleccionó la opción pertinente para registrar el producto, siga el enlace a la página de registro que se mostrará en la página de información sobre el producto.
En Windows, justo después de instalar Application Server Enterprise Edition, el agente de Message Queue presenta errores durante el inicio y se muestra un mensaje en el que se indica que no existe el directorio drive:\as\domains\domain1\imq.
Tenga en cuenta que si el agente se ejecuta después de iniciar domain1, Application Server creará el directorio y no habrá ningún problema.
Cree var_home_dir_location antes de crear el agente:
$imqbrokerd -varhome var_home_dir_location |
Por ejemplo:
$imqbrokerd -varhome D:\as\domains\domain1\imq |
La instalación de Application Server Edición Enterprise 8.2 en un sistema Red Hat Linux Advanced Server (RHLAS) 3.0 o 4.0 presentará errores si aún no se ha instalado la biblioteca compat-libstdc++ en el sistema. Application Server necesita la biblioteca compat-libstdc++ en los sistemas RHLAS, aunque no se instala de forma predeterminada. Tenga en cuenta que este problema sólo se produce en los sistemas RHLAS.
Descargue e instale el RPM de compat-libstdc++ desde http://rpm.pbone.net/index.php3/stat/4/idpl/843376/com/compat-libstdc++-7.3-2.96.118.i386.rpm.html antes de instalar el software de Application Server.
Al ejecutar Application Server Edición Enterprise 8.2 con Web Server 7.0 en el modo de 64 bits, los intentos de ejecutar una versión de 64 bits del complemento de equilibrador de carga fallan mostrando el siguiente error:
failure: CORE2253: Error running Init function load-modules: dlopen of /export/home/mareks/opt/webserver7/plugins/lbplugin/bin/libpassthrough.so failed (ld.so.1: webservd: fatal: /export/home/mareks/opt/webserver7/plugins/ lbplugin/bin/libpassthrough.so: wrong ELF class: ELFCLASS32) failure: server initialization failed |
El problema es que no hay disponible un complemento de equilibrador de carga de 64 bits para Application Server Edición Enterprise 8.2, y Web Server de 64 bits requiere complementos de 64 bits.
Puede determinar si Web Server se ejecutará en modo de 64 bits o de 32 bits utilizando el siguiente comando:
wadm get-config-prop --user=admin --config=xxx --password-file=xxx platform |
No hay programado ningún equilibrador de carga de 64 bits para Application Server Edición Enterprise 8.2. Para solucionar el problema, use la función de proxy inverso de Web Server 7.0 o configure Web Server 7.0 para ejecutarlo en modo de 32 bits. Consulte la documentación de Web Server para obtener instrucciones.
Al instalar Application Server 8.2 en la ubicación predeterminada en Windows 2000, es posible que aparezca el siguiente mensaje de error al ejecutar asant deploy:
$ C:/Sun/JavaES5/appserver/bin/asant deploy The input line is too long. The syntax of the command is incorrect. |
El problema es que las líneas de comando en Windows 2000 no pueden superar los 1000 caracteres de longitud y, en función de la configuración del sistema, el entorno predeterminado ANT_OPTS puede provocar que la línea del comando asant deploy sea larga. Esto sólo ocurre en Windows 2000.
En Windows 2000, instale Application Server en una ruta de directorio corta; por ejemplo, C:\JES5_AS.
Si Application Server está seleccionado en la parte superior del panel de instalación de componentes, el subcomponente agente de nodo estará también seleccionado de forma predeterminada al utilizar JES 5 b12 en Windows. El proceso de instalación crea un agente de nodo y una instancia de servidor llamado AppServer1 que pertenece a este agente de nodo. Este comportamiento es correcto.
No obstante, si el subcomponente agente de nodo no está seleccionado, el proceso de instalación continuará creando una instancia AppServer1 en el archivo common.properties del dominio; por ejemplo:
domain.name=domain1 appserver.instance=AppServer1 |
Los siguientes intentos de implementar las aplicaciones utilizando asant darán error.
Edite el archivo common.propeties sustituyendo appserver.instance=AppServer1 por appserver.instance=server.
A consecuencia de otros errores (posiblemente 6295215), el código proporcionado en la sección Obtaining a Physical Connection from a Wrapped Connection de Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide del Capítulo 11, Using the JDBC API for Database Access de Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide no es correcto. En concreto, la línea siguiente:
Connection drivercon = ds.getConnection(con); |
debería indicar:
Connection drivercon = ((com.sun.gjc.spi.DataSource)ds).getConnection(con); |
En esta versión de software, Application Server no admite el sistema de archivos de red (NFS).
ninguna.
Para ejecutar el tutorial de J2EE 1.4 en Sun Java System Application Server Edición Enterprise 8.2, lleve a cabo estas tareas:
Cuando edite el archivo /common/build.properties tal y como se describe en el apartado “About the Examples” del capítulo “About this Tutorial”, cambie también el puerto 4848 por el 4849.
Cuando use la herramienta de implementación (Deploytool), agregue el servidor localhost:4849 antes de implementar un ejemplo.
Cuando utilice la consola de administración para crear un recurso, use la ficha Targets (Destinos) para especificar el servidor como el destino. Si utiliza la línea de comandos o un destino asant, el servidor es el destino predeterminado y no es necesario realizar ninguna acción adicional.
En esta sección, se describen problemas conocidos relacionados con la administración del ciclo de vida, junto con las soluciones pertinentes.
[echo] Doing admin task set [exec] [Attribute(id=redelivery-interval-internal-in-millis) : Redelivery- Interval (7,000) should be greater than or equal to Minimum-delivery- interval-in-millis (9,000)] [exec] CLI137 Command set failed.
minimum-delivery-interval es el intervalo mínimo de duración entre las entregas del mismo temporizador periódico.
redelivery-interval-in-mills es el tiempo que debe esperar el servicio de temporizador para volver a intentar la entrega después de que se haya producido un error en ejbTimeout.
El problema es que la lógica que relaciona la propiedad de intervalo de reentrega con la propiedad de entrega mínima es incorrecta e impide que se utilice la GUI o la CLI para definir valores en los que el intervalo de entrega mínimo sea superior al intervalo de reentrega.
minimum-delivery-interval-in-millis debe ser igual o mayor que el valor de redelivery-interval-in-millis de la propiedad ejb-timer-service. El problema es que se produce una comprobación de validación errónea en Application Server al verificar que el valor de redelivery-interval-in-millis es superior al valor de minimum-delivery-interval-in-millis.
Use los valores predeterminados para estas propiedades, tal y como se indica a continuación:
minimum-delivery-interval(default)=7000 redelivery-interval-in-millis(default)=5000
Si utiliza valores que no sean los predeterminados, se generará un error.
Este apartado describe problemas conocidos relacionados con el registro, junto con las soluciones pertinentes.
Si establece la opción java.security.debug para JVM, la instancia del servidor se bloqueará irreversiblemente al iniciarse; por ejemplo, si establece domain.xml en los siguientes valores, se producirá este problema:
<jvm-options\>-Djava.security.debug=access,failure</jvm-options\>
Ninguna por ahora. Evite configurar este indicador.
Las ubicaciones predeterminadas de la instancia del servidor y del registro han cambiado en Sun Java System 8.2 en comparación con la versión 7.x.
Para obtener más información, consulte Sun Java System Application Server Enterprise Edition 8.2 Administration Guide o Sun Java System Application Server Enterprise Edition 8.2 Upgrade and Migration Guide .
Este apartado describe problemas conocidos relacionados con Java Message Queue, junto con las soluciones pertinentes.
Los errores al volverse a conectar en situaciones que dependen de temporizadores pueden estar causados por diversos problemas.
Puede solucionarlos de esta forma:
Reinicie los agentes involucrados
Reinicie las instancias involucradas de Application Server
Debido a un cambio reciente, cuando una escucha de mensaje asíncrono es el único subproceso activo en el contenedor app-client, el resto de la máquina virtual (VM) appclient existe en forma de daemon. Este comportamiento supone un regreso para las aplicaciones anteriores que realizaban recepciones asíncronas en ACC. Este problema afecta a los clientes de la aplicación que configuran un módulo de escucha de mensajes JMS y salen del subproceso principal.
No salga del subproceso principal. Espere a que la escucha del mensaje informe al subproceso principal antes de detenerlo.
Este apartado describe problemas conocidos relacionados con la supervisión, junto con las soluciones pertinentes.
En la página de configuración del nivel de supervisión, si cambia el servicio del conector o el nivel de supervisión del conjunto de conexiones del conector a LOW o HIGH y, a continuación, guarda los cambios, ninguno de los dos se cambia en el archivo domain.xml del dominio. Sin embargo, si cambia el nivel de supervisión de servicio de JMS a LOW o HIGH y guarda esta modificación, los valores del servicio del conector y del conjunto de conexiones del conector también se cambian al mismo tiempo. Este problema no se produce cuando se ejecutan los comandos equivalentes desde la línea de comandos.
Utilice sólo el componente de servicio JMS de la página de nivel de supervisión para cambiar los niveles de supervisión.
Al visualizar las estadísticas de supervisión de algunos elementos en el servicio HTTP, algunos valores que se presentan no se corresponden con los valores reales o se muestran siempre como 0. Específicamente, las siguientes estadísticas de servicio HTTP no muestran información aplicable para Application Server y, en consecuencia, hay que hacer caso omiso de ellas:
http-service load1MinuteAverage load5MinuteAverage load15MinuteAverage rateBytesTransmitted rateBytesReceived
pwc-thread-pool (the element)
Por ejemplo:
EJBModuleMonitorMap().size() = 1 eventhough ejb module is undeployed EJBModuleMonitor().getName() = sqe_ejb_s1_01 |
Este hecho es verdadero para aplicaciones y módulos EJB. Desde el punto de vista de la programación (mediante MBeanAPI) y mediante asadmin list/get, sigue existiendo todavía un MBean de supervisión vacío.
asadmin list -m "server.applications" shows the following output: server.applications.MEjbApp server.applications.__ejb_container_timer_app server.applications.adminapp server.applications.admingui server.applications.com_sun_web_ui server.applications._export_install_nov-11_domains_domain1_applications _j2ee-modules_sqe_ejb_s1_01 |
Puede consultar las estadísticas:
bin/asadmin list -m "server.applications._export_install_nov-11_domains _domain1_applications_j2ee-modules_sqe_ejb_s1_01" server.applications._export_install_nov-11_domains_domain1_applications_ j2ee-modules_sqe_ejb_s1_01.SQEMessage server.applications._export_install_nov-11_domains_domain1_applications_ j2ee-modules_sqe_ejb_s1_01.TheGreeter |
Una vez que anule la implementación:
_export_install_nov-11_domains_domain1_applications_j2ee-modules_sqe_ ejb_s1_01 |
Si ejecuta un comando de enumeración, seguirá viendo la aplicación:
asadmin list -m "server.applications" server.applications.MEjbApp server.applications.__ejb_container_timer_app server.applications._export_install_nov-11_domains_domain1_applications_ j2ee-modules_sqe_ejb_s1_01 server.applications.adminapp server.applications.admingui server.applications.com_sun_web_ui |
pero no contiene estadísticas de supervisión:
asadmin list -m "server.applications._export_install_nov-11_domains_ domain1_applications_j2ee-modules_sqe_ejb_s1_01" Nothing to list at server.applications.-export-install-nov-11-domains- domain1-applications-j2ee-modules-sqe-ejb-s1-01. |
Para obtener los nombres válidos que comiencen por una cadena, utilice el carácter comodín ("` *"). Por ejemplo, para enumerar los nombres de todas las entidades que se pueden supervisar que comiencen por server, use list "server.*".
Es un problema inocuo. El módulo se puede volver a implementar con seguridad sin que se produzcan problemas. La supervisión raíz Mbean no se elimina, sino que se queda vacía.
Esta sección describe cómo reconocer y asociar soluciones relacionadas con Java Data Objects y Container-Managed Persistence
Esta excepción se inicia si una cadena de dependencias clave externa entre instancias modificadas (o creadas) en una transacción es el resultado de una dependencia circular en la base de datos.
Separe el juego original de operaciones en transacciones múltiples.
Este apartado describe problemas conocidos relacionados con PointBase, junto con las soluciones pertinentes.
En el caso de un conjunto de conexiones JDBC que señale a una instalación de base de datos PointBase, al definir el atributo transaction-isolation-level pool en cualquier valor distinto del predeterminado (Connection.TRANSACTION_READ_COMMITTED) se generará una excepción. Sin embargo, si establece este mismo parámetro en un valor que no sea el predeterminado para los conjuntos que hacen referencia a otras bases de datos, no se producirá ninguna excepción.
En el caso de los conjuntos de conexiones JDBC que hacen referencia a una instalación de base de datos PointBase, no intente configurar la opción transaction-isolation-level.
En ocasiones, la aplicación PointBase integrada desencadena una excepción si el controlador del servidor de red y el controlador integrado se utilizan simultáneamente.
Use el controlador integrado o uno de red, pero no los dos juntos.
Al actualizar a Application Server Edición Enterprise 8.2, la revisión de la versión de actualización sobrescribe la base de datos predeterminada de Pointbase.
Vuelva a crear o a introducir los esquemas o los datos que existían antes de la actualización. Si ha implementado aplicaciones con Beans CMP con la opción para generar tablas, deberá anular la implementación o volver a implementar la aplicación para que se vuelvan a generar las tablas.
En esta sección, se describen problemas conocidos relacionados con el código de ejemplo incluido en el producto Application Server 8.2.
Desde install_dir\samples\ee-samples\failover\apps\mqfailover\docs\index.html, si se ejecutan los siguientes comandos:
Consola 1
cd install_dir\samples\ee-samples asant start-mq-master-broker1 |
Consola 2
cd install_dir\samples\ee-samples asant start-mq-cluster-broker1 |
Consola 3
cd install_dir\samples\ee-samples asant start-mq-cluster-broker2 |
Consola 4
cd install_dir\samples\ee-samples asadmin start-domain domain1 |
Si ya ha ejecutado asant setup-one-machine-cluster-without-ha o asant setup-one-machine-cluster-with-ha para otro ejemplo de Enterprise Edition, ejecute asant configure-mq o bien asant setup-one-machine-cluster-and-configure-mq. En este caso, el comando parece que se ejecuta correctamente:
start_nodeagent: [echo] Start the node agent cluster1-nodeagent [exec] Command start-node-agent executed successfully. |
Pero el sistema se bloquea definitivamente.
Ninguna por ahora. Este problema afecta de forma parecida a todos los ejemplos de Enterprise Edition que utilizan este destino ant en Windows. Una solución consiste en pulsar Ctrl+C para cancelar el proceso y luego volver a ejecutarlo.
El error que se produce es el siguiente:
/opt/SUNWappserver/domains/domain1/config/sun-acc.xml -name MQFailoverTestClient -textauth -user j2ee -password j2ee Nov 18, 2004 10:50:17 PM com.sun.enterprise.naming.NamingManagerImpl bindObjects SEVERE: NAM0006: JMS Destination object not found: jms/durable/TopicA Nov 18, 2004 10:50:18 PM com.sun.enterprise.naming.NamingManagerImpl bindObjects SEVERE: javax.naming.NameNotFoundException javax.naming.NameNotFoundException |
La documentación no indica explícitamente que los recursos JMS se deban crear manualmente si se lleva a cabo una implementación manual utilizando comandos asadmin deploy ni que haya que usar los destinos Ant especificados para implementar la aplicación de ejemplo.
Use el destino de implementación asant para la secuencia de comandos build.xml, lo que crea los recursos JMS necesarios para ejecutar la aplicación.
Cuando se implementa el ejemplo install_dir/samples/webservices/security (basicSSl) en Linux, el certificado no se crea y se muestra un error similar al siguiente:
generate_certs: [echo] ***Exporting certificate from NSS database [exec] Result: 1 [echo] ***Generating Java Keystore from generated certificate [exec] keytool error: java.lang.Exception: Input not an X.509 certificate [exec] Result: 1 [echo] ***Generating Java trust store from generated certificate [exec] keytool error: java.lang. Exception: Input not an X.509 certificate [exec] Result: 1 . . . generate_certs: [echo] ***Exporting server certificate from NSS database to a PKCS12 certificate file [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/ libnss3.so: version `NSS_3.9' not found (required by /opt/sun/appserver/lib/ pk12util) [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: version `NSS_3.6' not found (required by /opt/sun/appserver/lib/pk12util) [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: version `NSS_3.7' not found (required by /opt/sun/appserver/lib/pk12util) [exec] Result: 1 |
El problema es que la ubicación de las bibliotecas NSS es distinta en Linux y en Solaris. Debe asegurarse de que LD_LIBRARY_PATH señale a las bibliotecas NSS adecuadas a la hora de realizar la implementación en Linux. Defina LD_LIBRARY_PATH en su entorno o bien ajuste la secuencia de comandos del empaquetador del shell install_dir/bin/asant.
Lleve a cabo una de las siguientes acciones:
Configure LD_LIBRARY_PATH=/opt/sun/private/lib.
Agregue la siguiente línea a la secuencia de comandos install_dir /bin/asant.
LD_LIBRARY_PATH=$AS_NSS:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH |
Después de actualizar desde Application Server Platform Edition 8.0 a Application Server Edición Enterprise 8.2, puede recibir un error HTTP 404 "File not found" (Archivo no encontrado) al intentar acceder a la página de ejemplos.
Copie los documentos de ejemplo de los dominios de la versión 8.0 a los dominios de 8.2.
Si se instala Application Server Edición Enterprise 8.2 en una zona global de Solaris y un dominio de Application Server se instala seguidamente en una zona local dispersa, puede experimentar problemas al ejecutar las aplicaciones de ejemplo si los permisos de archivos del dominio en la zona dispersa no están suficientemente abiertos durante el proceso de implementación.
Durante el proceso de implementación, asegúrese de que Application Server puede recuperar el archivo JAR del cliente, xmsClient.jar, y copie éste en la ubicación de ejemplo, (/usr/SUNWappserver/appserver/samples/webservices/security/ejb/apps/xms/xmsClient.jar ). Esto suele hacerlo automáticamente el grupo de ejemplos, pero fallará si los permisos en xmsClient.jar no están abiertos.
Este apartado describe problemas conocidos relacionados con los certificados y la seguridad de las aplicaciones web y Application Server, junto con las soluciones pertinentes.
Las aplicaciones WebServiceSecurity no se pueden ejecutar con J2SE 5.0 por los siguientes motivos:
J2SE 5.0 PKCS11 no es compatible con el modo UNWRAP
J2SE 5.0 PKCS11 no admite RSA/ECB/OAEPWithSHA1AndMGF1Padding con PKCS11
El equipo de J2SE ha presentado el documento "CR 6190389: Add support for the RSA-PKCS1 and RSA-OAEP wrap/unwrap mechanisms" (CR 6190389: adición de compatibilidad con los mecanismos de empaquetado y desempaquetado RSA-PKCS1 y RSA-OAEP) para este error.
Use J2SE 1.4.2 con cualquier otro proveedor JCE (no el que se incluye de forma predeterminada). Tenga en cuenta que la compatibilidad con el acelerador de hardware no está presente en esta configuración.
Cuando se configura el equilibrador de carga (hardware) para la finalización de SSL, Application Server cambia el protocolo https por http durante la redirección.
Agregue un equilibrador de carga de software entre el equilibrador de carga de hardware y Application Server.
En esta sección, se describen problemas conocidos relacionados con la utilidad de actualización, junto con las soluciones pertinentes.
Al ejecutar la utilidad de actualización e identificar install_dir como el directorio de instalación de origen, el proceso de actualización actualiza sólo los dominios que se crean en el directorio install_dir /domains. Los dominios creados en otras ubicaciones no se actualizan.
Antes de iniciar el proceso de actualización, copie todos los directorios del dominio desde sus ubicaciones en el directorio install_dir /domains.
Este problema se ha observado en varios sistemas Linux y es más frecuente en Java Desktop System 2, pero también se ha detectado en distribuciones RedHat.
Después de hacer clic en el botón Herramienta para iniciar la actualización de la pantalla final del programa de instalación, éste no logra iniciarla para completar el proceso y se bloquea de forma indefinida, por lo que no consigue volver a la línea de comandos.
Este problema no se produce si se utiliza el modo de instalación mediante línea de comandos para llevar a cabo la actualización "in situ".
Si realiza dicha actualización en modo de GUI y se encuentra con este problema, salga del instalador pulsando Ctrl+C en la ventana de terminal en la que se inició el instalador.
Inicie la herramienta de actualización desde la ventana de terminal usando los siguientes comandos:
install_dir/bin/asupgrade --source install_dir/domains --target install_dir --adminuser adminuser--adminpassword adminpassword --masterpassword changeit |
adminuser y adminpassword deben coincidir con los valores usados para la instalación que esté actualizando.
Cuando la herramienta de actualización complete el proceso, podrá iniciar también el explorador y especificar la siguiente URL para visualizar la página que muestra información acerca del producto:
file://install_dir/docs/about.html
Si seleccionó la opción pertinente para registrar el producto, siga el enlace a la página de registro que se mostrará en la página de información sobre el producto.
Elimine las siguientes entradas del destino domain.xml (después de la actualización) y reinicie el servidor:
<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>
Al actualizar de Application Server 7.x a 8.2, puede producirse un conflicto de puertos entre la antigua y la nueva instalación, muy probablemente con los puertos predeterminados 8080 y 8181.
Cambie los puertos utilizados en Application Server 8.2 para resolver el conflicto.
Hay dos aspectos de este problema:
Si se ejecutan las secuencias de comandos de configuración de aplicaciones de ejemplo que utilizan la base de datos Derby, ésta se crea en el directorio actual o en <install_root>/bin.
La secuencia de comandos de ejemplo de build de Ant crea un archivo password.txt que guarda el archivo de contraseña de administración en el directorio actual, en el que no se podrá escribir en situaciones de zonas dispersas o que no sean root .
Ubicación de la base de datos Derby: utilice la opción --dbhome con el comando start-database para crear la base de datos en el valor especificado para --dbhome. Por ejemplo, a continuación, se encuentra la sintaxis de comando asadmin para start-database.
start-database [--dbhost 0.0.0.0] [--dbport 1527] [--dbhome db_directory] [--echo=false] [--verbose=false] |
Ubicación del archivo password.txt : es previsible que el directorio de ejemplos permita su escritura, ya que todos los comandos integrados incluyen la creación de un archivo password.txt en ese directorio. Asegúrese de que instala una copia de los ejemplos que funcione en una ubicación con permiso de escritura.
Este problema se produce cuando se ejecuta la instalación mediante actualización utilizando credenciales de administración distintas a las predeterminadas.
Cuando realice una actualización en paralelo utilizando el programa de instalación basado en archivos de 8.xPE a 8.2EE, utilice las siguientes credenciales de administración para el nuevo Application Server:
usuario de administración: admin
contraseña de administración: adminadmin
contraseña maestra: changeit
Tras la actualización, puede cambiar estas contraseñas si es necesario.
La herramienta de actualización puede detectar una entrada de directorio existente, aunque no válida, para el campo de directorio de origen y da la impresión de que la configuración del directorio es correcta.
Debería aparecer un mensaje âInvalid directoryâ (directorio no válido) cuando se introduce una ruta incorrecta al directorio de origen. Aparece un mensaje de directorio no válido si se introduce /opt/SUNWappserverEE81UR2/ para el directorio de origen. Sin embargo, si se introduce /opt/SUNWappserverEE81UR2/domains , la herramienta continúa con el proceso de actualización sin advertir que la ruta no es válida. Este problema es similar al ID 6440710, excepto que el comportamiento es distinto dependiendo del valor de entrada.
Al actualizar de Application Server 7 u 8.x a Application Server 8.2, debe incluirse primero el valor recomendado en la documentación en el directorio de origen: la raíz del dominio para el directorio in situ y de dominio para actualizaciones en paralelo.
La instalación de Application Server Edición Enterprise 8.2 no permite caracteres especiales en el nombre de usuario de administración. La creación del dominio fallará si se utiliza cualquier carácter especial. Sin embargo, tenga en cuenta que la contraseña de administración puede tener caracteres especiales.
Al actualizar de Application Server 7 a Application Server 8.2, verifique que el nombre de usuario de administración no contiene ningún carácter especial.
En esta sección, se describen problemas conocidos relacionados con el contenedor web, junto con las soluciones pertinentes.
Si solicita una precompilación de JSP cuando implemente una aplicación en Windows, los siguientes intentos para anular la implementación o para volver a implementarla (o alguna aplicación con el mismo ID de módulo) no funcionarán tal y como se esperaba. El problema es que la precompilación de JSP abre archivos JAR en la aplicación, pero luego no los cierra y Windows impide que se anule la implementación porque no se pueden eliminar los archivos e impide que se puedan volver a implementar, puesto que no se pueden sobrescribir.
Tenga en cuenta que la anulación de la implementación es correcta hasta un punto en el que la aplicación se elimina lógicamente de Application Server. Tenga en cuenta también que la utilidad asadmin no muestra ningún mensaje de error, a pesar de que los archivos JAR bloqueados y el directorio de la aplicación siguen estando en el servidor. El archivo de registro del servidor contiene mensajes en los que se indica que no se han podido eliminar los archivos ni el directorio de la aplicación.
Los intentos de volver a implementar la aplicación después de que ésta se haya anulado fallan porque el servidor trata de eliminar los archivos existentes y el directorio, pero estos intentos fallan. Esto puede suceder si intenta implementar una aplicación que utilice el mismo ID de módulo que la aplicación que se implementó originalmente porque el servidor utiliza dicho ID de módulo cuando elige el nombre del directorio para conservar los archivos de la aplicación.
Si intenta reimplementar la aplicación sin anular su implementación primero, se producirán fallos por las mismas razones.
Si intenta volver a implementar la aplicación o implementarla después de haberla eliminado, la utilidad asadmin devuelve un error semejante al siguiente.
An exception occurred while running the command. The exception message is: CLI171 Command deploy failed : Deploying application in domain failed; Cannot deploy. Module directory is locked and can't be deleted. |
No se producirá este problema, si especifica --precompilejsps=false (la configuración predeterminada) al implementar una aplicación. Tenga en cuenta que el primer uso que haga de la aplicación desencadenará la compilación JSP, por lo que el tiempo de respuesta para la primera solicitud será superior al de las solicitudes posteriores.
Debe saber también que si realiza una compilación previa, deberá detener y reiniciar el servidor antes de anular la implementación de la aplicación o de volver a implementarla. Al cerrar, se liberan los archivos JAR bloqueados por lo que la anulación de la implementación o el proceso para volver a implementar se realizarán correctamente.
El elemento opcional load-on-startup servlet en web.xml indica que el servlet asociado se debe cargar e iniciar cuando se inicie la aplicación web de la que forma parte.
El contenido opcional de este elemento es un entero que indica el orden en el que se debe cargar e iniciar el servlet con respecto a los demás servlets de la aplicación web. Si <load-on-startup> está vacío, indica que el orden no es relevante, siempre y cuando el servlet se cargue e inicie durante el inicio de la aplicación web que lo contiene.
El esquema de Servlet 2.4 de web.xml ya no admite un elemento <load-on-startup> vacío. Esto implica que debe especificarse un entero al utilizar un archivo web.xml basado en Servlet 2.4. Si se especifica un elemento <load-on-startup> vacío, como en <load-on-startup/>, el archivo web.xml no podrá realizar la validación en el esquema de Servlet 2.4 para web.xml, por lo que fallará la implementación de la aplicación web.
Problema de compatibilidad con versiones anteriores En el caso de web.xml basado en Servlet 2.3, sí se puede dejar vacío <load-on-startup>.
Especifique <load-on-startup>0</load-on-startup> al utilizar un archivo web.xml basado en Servlet 2.4 para indicar que el orden de carga del servlet es irrelevante.
Se puede acceder a la página JSP, pero se producen fallos al compilar y el registro del servidor contiene el mensaje de error "Unable to execute command", es decir, que no se puede ejecutar el comando con este seguimiento de pila:
at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher. exec(Execute.java:655) at org.apache.tools.ant.taskdefs.Execute. launch(Execute.java:416) at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:427) at org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter. executeExternalCompile(DefaultCompilerAdapter.java:448) at org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute (JavacExternal.java:81) at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842) at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682) at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:396) |
Defina el conmutador de compilación "fork" de JSP en "false".
Esta acción puede realizarse de dos formas:
Globalmente, al configurar el parámetro fork init de JspServlet en ${S1AS_HOME}/domains/domain1/config/default-web.xml en false:
<servlet> <servlet-name>jsp</servlet-name> <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class> .... <init-param> <param-name>fork</param-name> <param-value>false</param-value> </init-param> .... </servlet> |
En cada aplicación web, configurando la propiedad de configuración JSP fork de sun-web.xml en false:
<sun-web-app> <jsp-config> <property name="fork" value="false" /> </jsp-config> </sun-web-app> |
Las dos configuraciones impedirán que ant genere nuevos procesos para la compilación javac.
Sun Java System Application Server Edición Enterprise 8.2 agrega compatibilidad para la función proporcionada por la función del complemento auth-passthrough, que está disponible con Sun Java System Application Server Edición Enterprise 7.1. Sin embargo, en Application Server Edición Enterprise 8.2, la función del complemento auth-passthrough está configurada de forma diferente.
La función del complemento auth-passthrough en Application Server Edición Enterprise 7.1 ha resultado útil en situaciones de implementación de dos capas:
La instancia de Application Server está protegida por un segundo servidor de seguridad detrás del servidor de seguridad corporativo.
No se permiten conexiones de clientes directamente a la instancia de Application Server:
En arquitecturas de red de este tipo, un cliente se conecta a un servidor web de principal (front-end) que se haya configurado con la función del complemento service-passthrough y reenvía solicitudes HTTP a la instancia de Application Server que actúa de proxy para que las procese. La instancia de Application Server sólo puede recibir solicitudes desde el proxy del servidor web, pero nunca directamente de los hosts clientes. En consecuencia, ninguna aplicación implementada en la instancia de Application Server que actúa de proxy que solicite información del cliente (como pueda ser la dirección IP del cliente) recibirá la IP de host del proxy, puesto que éste es el host que origina la solicitud remitida.
En Application Server Edición Enterprise 7.1, la función del complemento auth-passthrough se puede configurar en la instancia de Application Server que actúa como proxy para hacer que la información de los clientes remotos esté disponible directamente para todas las aplicaciones implementadas; de esta forma, el funcionamiento es como si la instancia de Application Server que actúa de proxy hubiera recibido la solicitud directamente en lugar de a través del servidor web intermediario que ejecuta el complemento service-passthrough.
En Application Server Edición Enterprise 8.2, la función auth-passthrough puede habilitarse configurando la propiedad authPassthroughEnabled del elemento <http-service> de domain.xml como TRUE (verdadero), de la siguiente forma:
<property name="authPassthroughEnabled" value="true"/> |
Las mismas consideraciones de seguridad de la función del complemento auth-passthrough de Application Server Edición Enterprise 7.1 se aplican también a la propiedad authPassthroughEnabled de Application Server Edición Enterprise 8.2. Como, con authPassthroughEnabled, es posible sustituir la información que se podría utilizar para la autenticación (como la dirección IP desde la que se origina la solicitud o el certificado SSL de cliente), es esencial que sólo los clientes o los servidores de confianza puedan conectarse a la instancia de Application Server Edición Enterprise 8.2 con el comando authPassthroughEnabled definido como TRUE (verdadero). Como medida de precaución, se recomienda que sólo los servidores que estén detrás de un servidor de seguridad corporativo se configuren con authPassthroughEnabled establecido en TRUE (verdadero). Un servidor que esté accesible a través de Internet nunca debe configurarse con authPassthroughEnabled definido en TRUE (verdadero).
Tenga en cuenta que en una situación en la que el servidor web proxy se haya configurado con el complemento service-passthrough y éste reenvíe solicitudes a una instancia de Application Server 8.1 Update 2 con authPassthroughEnabled definido como TRUE (verdadero), la autenticación SSL de cliente puede habilitarse en el servidor web proxy y deshabilitarse en la instancia de Application Server 8.1 Update 2 que actúa de proxy. En este caso, la instancia de Application Server 8.1 Update 2 seguirá considerando la solicitud como si estuviera autenticada a través de SSL y proporcionará el certificado SSL de cliente a cualquier aplicación implementada que lo solicite.
Al crear un httplistener con el indicador --enabled=false, el módulo de escucha no llega a deshabilitarse. El indicador --enabled no tiene efecto alguno cuando se utiliza al mismo tiempo que se crea el módulo de escucha.
Cree el módulo de escucha con un estado habilitado; deshabilítelo manualmente más tarde.
En Windows, al reimplementar una aplicación que crea un usuario antes de la implementación, el comando create-file-user puede fallar porque verify_file_user_exists_common no se ejecuta (aunque se le llame), y no notifica que el usuario ya existe. La ejecución de deploy se detiene en este punto, y la implementación, así como la anulación de la implementación, fallan.
Elimine primero los usuarios de archivos que utilizan keydel y, a continuación, ejecute deploy de nuevo:
asant keydel asant deploy |