h1

La diferencia que puede hacer una versión de Java

02/25/2009

Wizdoc [Icon By Buuf]

 Tips & Tricks.

En estos días que he estado asignado como sysadmin, he tenido entre otras tareas, las de instalación, configuración y gestión de varios Weblogic Application Servers en los ambientes de preproducción y producción del cliente. Esto incluye resolver problemas como aplicaciones que tiran el Weblogic e instancias que de repente dejan de responder.

De entre varios casos para la araña[1], uno especialmente significativo es una aplicación web "sencilla" (sólo JSPs y servlets, sin EJBs ni frameworks ORM como Hibernate) que después de un tiempo de haber sido deployada en el application server, generaba un error CORE de sistema, tirando el servidor y dejando un core dump de casi 700 MB de longitud. Desde el principio se descartó un problema de hardware, pues en la misma máquina estaban corriendo otras instancias de la misma aplicación para otros países sin ningún problema.

El diagnóstico

Como mencioné anteriormente, se deployaba la aplicación y al navegar por la misma, llegaba a un punto en el que provocaba la caída del servidor, generando un core dump en el directorio de la instancia del Weblogic. Como referencia incluyo algunos parámetros de la configuración:

Hardware

Sun Fire V240

Sistema Operativo

Solaris 5.8

Application Server

Weblogic 8.1 SP4

Versión de Java

1.4.2_05 (la que viene con Weblogic)

Aplicación

Struts con JDBC vía pools administrados por Weblogic

Otros

Un archivo "core" alojado en <weblogic_root>/user_projects/domains/<domain_name>/

De primera instancia se me pidió revisar el contenido del archivo core, que pude ver con relativa facilidad gracias al script localizado en este sitio. Por otro lado, en el mismo directorio se encontraba un archivito hs_err<process_id> con la explicación del problema. Su contenido se describe en la base de datos de bugs de Sun.

La solución

En aquélla página describen el problema como un segmentation fault que ocurre cuando se abren ciertos streams de datos: en este caso, al ejecutar consultas muy extensas sobre una base de datos[2]. Lo lamentable del asunto es que no existe una solución obvia y sólo se sugieren un par de workarounds, incluyendo la precarga de una librería que viene con el JDK para Solaris sparc:

export LD_PRELOAD=<weblogic_root>/ jdk142_05/ jre/ lib/ sparc/ libjsig.so

Por cierto, para este caso específico, dichas soluciones no funcionaron, pues se seguía cayendo el servidor.

Sin embargo, una solución real consistió en cambiar la máquina virtual de Java por una versión más reciente. Esto requería instalar el JDK sin reemplazar otras versiones y configurar los scripts de arranque del application server para que tomaran la nueva ruta. Así entonces, se realizó la instalación de la versión 1.4.2_19 de Java y se modificaron los valores del correspondiente StartWeblogic.sh:

#Path al JDK
#———–
#JAVA_HOME="$WL_DIR/ jdk142_05" — Línea Comentada

# Path al JDK 142_19 (Ultima version para este JDK) - Corriendo a 32 bits
JAVA_HOME="/ usr/ <weblogic_user>/ <java_installations>/ j2sdk1.4.2_19"

¿El resultado? No sólo no se cayó la instancia, sino que mejoró notablemente el desempeño de la aplicación; al grado que previo set de pruebas y certificación por el usuario, se realizaron las mismas modificaciones en las demás instancias del Weblogic.

La moraleja de la historia

Si la aplicación en Java está provocando la caída del application server y el hardware o la configuración del sistema operativo no son factores, es una buena idea pasar a la última versión estable de la máquina virtual, porque la mayoría de las versiones revisadas tienen mejoras y optimizaciones en el código de la JVM que generalmente incluyen correcciones de bugs. Adicionalmente podremos descartar errores en la aplicación misma o fallas en el application server. Si al sysadmin le da frío hacer un intercambio de versiones de Java, es posible cambiar sólo la versión de la instancia problemática a través de los scripts de arranque, instalando los componentes del JDK sin reemplazar[3] la versión de Java "por defecto" y sin afectar otras instancias.

Para terminar, esto nos lleva a un tema más general: siempre es necesario tener una buena gestión de la configuración, pues si se presentan incidencias como ésta, es factible rastrear cuál es la causa. Esto se logra de primera instancia mediante una matriz de configuraciones soportadas, sobre todo cuando estamos hablando de integrar más de dos o tres productos. Finalmente, con estas matrices podremos realizar comparativos entre configuraciones parecidas: en el caso mostrado el problema tiene su raíz en la JVM; no en la aplicación, el servidor ni el sistema operativo pues existían configuraciones similares que no presentaban problemas.

Notas y pies de página

1. Un caso para la araña es una frase que se remonta a las historietas de La pequeña Lulú (1945) donde con cierta regularidad resolvían problemas "detectivescos". Los casos más difíciles y extraños eran resueltos por Tobi (amigo de Lulú y apodado "La Araña"). De ahí que la frase signifique "un problema cuyo origen es difícil de encontrar y su solución es más elusiva aún".

2. En este caso, dichas consultas eran exactamente las mismas en todas las instancias de la aplicación, pero la que estaba dando problemas obtenía como resultado un número muy elevado de registros. Por ello se consideró que tarde o temprano el problema se presentaría en todas las instancias (debido al incremento progresivo del número de registros en la tabla consultada) y se optó por corregir el problema de raíz.

3. Para Solaris y Linux, sólo las versiones ejecutables (por ejemplo, j2sdk-1_4_2_19-solaris-sparc.sh) pueden instalarse sin necesidad de tener el usuario root ni reemplazar versiones de Java preexistentes. Por el contrario, aquellas versiones que vienen como archivos comprimidos con packages en su interior (por ejemplo, j2sdk-1_4_2_19-solaris-sparc.tar.Z) requieren del usuario root para ejecutarse e instalarse con el comando pkgadd.

One comment

  1. Hola como estas?, yo aqui de metiche en tu espacio, muy interesante por cierto, y si a veces la solucion es muy obvia, pero nos vamos por soluciones buscando a esa araña, que por lo comun se camuflajea demsiado bien en las paredes de la obviedad. Saludos y gracias por escribir y compartir tus experiencias y conocimientos.



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: