En Guardia!!!

Pues eso, las 2:20 de la mañana y aquí esta uno, porque la nueva tienda online del cliente presenta interbloqueos..... desde la facultad no veía uno, y esta semana nos está dando guerra el temita.De nuevo la baja calidad del desarrollo a quien j*** es al administrador.
En fin, a las cosas prácticas.

Como detectamos el interbloqueo? En nuestro caso lo tenemos entre hilos del web container, así que en las trazas empezamos a ver lo siguiente:

[...]
[12/21/07 0:39:04:758 CET] 0000000e ThreadMonitor W WSVR0605W: Thread "WebContainer : 1481" (00000703) has been active for 709361 milliseconds and may be h
ung. There is/are 49 thread(s) in total in the server that may be hung.
[12/21/07 0:39:04:760 CET] 0000000e ThreadMonitor W WSVR0605W: Thread "WebContainer : 1492" (00000710) has been active for 660530 milliseconds and may be h
ung. There is/are 50 thread(s) in total in the server that may be hung.

Bien, lo primero que nos dice nuestro WebSphere es que el ThreadMonitor está detectando las hebras que podrían estar colgadas (bien por nuestro servidor!). En nuestro caso sabemos que son del webcontainer, pero podrían ser de cualquier tipo. En este momento se impone hacer cun volcado de threads. En nuestro caso, con máquinas HP-UX, haremos un "kill -3 ". Eso vuelca en el native_stdout un threaddump que analizaremos.Para ello editamos el native_stdout.log (Otro día explicaré alguna herramienta de análisis de ThreadDump que nos ofrecen los buenos chicos de AlphaWorks)

Al final de nuestro threaddump vemos una frase interesante:

Found 1 deadlock.

Si nos remontamos en la fichero, veremos la causa y los hilos implicados en el bloqueo.

Found one Java-level deadlock:
=============================
"Non-deferrable Alarm : 3":
waiting to lock monitor 600000000540a108 (object 9fffffff5f741d60, a xxx.yyy.zzz),
which is held by "WebContainer : 1433"
"WebContainer : 1433":
waiting to lock monitor 600000000540a1b0 (object 9fffffff3f1a2630, a xxx.yyy.zzz),
which is held by "Non-deferrable Alarm : 3"

Por si hay más dudas, despues de eso en el fichero os mostrará el Java stack para los procesos implicados en el interbloqueo. Como entenderéis por razones de confidencialidad no puedo poner más de la traza, pero creo que queda claro como hacer un diagnóstico.

Nota final: Como nota os diré que bloquear y llenar el threadpool de WebSphere acaba por provocar el "cuelgue" de los servidores web que tengamos delante. Tanto para el WAS como para el web, llegados a este punto la única solución es el reinicio. Cierre de incidencia en guardia y a la camita...