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...

El tiempo...lo que no sobra nunca es el tiempo.....

Poco a poco voy preparando el blog, al menos en mi cabeza, pero siempre tengo el mismo problema... el tiempo. Nunca tengo tiempo de nada. En el trabajo me pasa lo mismo. Tenemos decenas de aplicaciones instaladas en servidores con todos los parámetros por defecto porque no hay tiempo para estudiarlos, ni para parametrizarlos, ni para nada. Lo peor de todo es que tenemos decenas de ideas para implementar, para mejorar el entorno, y no tenemos tiempo para prepararlas. Lo cual me lleva a tres reflexiones (obligatoriamente rápidas, como no, por falta de tiempo):
1) ¿Cuantos servidores de aplicaciones funcionarán en entornos productivos con todos sus parámetros por defecto sin que nadie considere esto una prioridad?
2) ¿Cuantas ideas se quedan por el camino en equipos con gente tremendamente preparada (tengo la fortuna de compartir trabajo con gente extraordinaria en todos los aspectos) dedicada a tareas de nivel inferior?
3) Servidores de aplicaciones como WebSphere, absolutamente cargados de todo tipo de funcionalidades y soluciones, pecan en muchos casos de dificultad o imposibilidad de realizar tareas de administración básica sobre ellos, que cada administrador suple con sus soluciones, scripts, trucos, etc. (Lo cual me llevará a otra entrada del blog....).¿por qué se dota de potencia una aplicación y su entorno de administración queda tan limitado, quedando en muchos casos inalterado una vez que se le ha dado una forma comercialmente vendible, pero de la que los que sufrimos conocemos sus carencias?

Supongo que esto ocurre en todos los ámbitos y a todo el mundo un poco, pero ultimamente me resulta sumamente frustrante

P.D. Lo reconozco. En lugar de elaborar más el post he perdido (o ganado) el tiempo visitando una sugerencia de un buen amigo. Todo el que tenga relación con mi ciudad (Segovia) sabrá quien es Aurelio Martin. Pues este es su blog, que por su puesto pasa desde hoy mismo a mis enlaces.
http://unacol.blogspot.com/

Un poco de historia

Mientras voy preparando los enlaces de mi recien estrenado (y aun en obras) blog, me he cruzado con esta historia resumen de WebSphere en serverwatch....

http://www.serverwatch.com/trends/article.php/3713471

¿Será capaz IBM de adaptarse lo suficiente como para abarcar todas las tecnologías y mantenerse como lider incluso si las alternativas a java empiezan a coger peso?

Versiones y mas versiones.....

Hoy por enésima vez hemos vuelto a hacer algo que me parece cuando menos parádojico. Hemos bajado de versión WebSphere para poder instalar una aplicación ya que sus desarrolladores no la han "certificado" para la versión 6.1.
Como digo no es la primera vez que nos pasa, y el cliente lo acepta, porque claro, a ver quien es el que se la juega para que luego haya algún fallo y que le cuelguen la responsabilidad de instalar contra lo que dice el proveedor......pero lo cierto es que es absurdo. La realidad de lo que hacemos es añadir de manera consciente cientos de bugs a nuestro servidor de aplicaciones.
No sé si esto es habitual, supongo que sí, principalmente en clientes grandes como en los que siempre he trabajado. ¿Por que no se certifican las versiones para la versión última de servidor? ¿Por que se agarran a una versión con bugs para no dar soporte en otra superior? Al final, quien más pierde, el administrador, que tiene la versión impuesta por el proveedor de la aplicación, y que debe hacerla funcionar como si fuera la última de cara al cliente....

Segundo paso...

Configurado Google Analitycs. Es curioso lo complejas que pueden ser algunas cosas. Lo que debería ser un cut&paste sobre la plantilla de blogger no es tan sencillo, y arroja en ocasiones errores incomprensibles. ¿Como lo harán esas personas que aparecen a veces en TV que son mayores y no saben de informatica pero tienen un blog? Supongo que tienen a alguien detrás que lo mantiene y ellos no son más que marketing. Poco a poco empiezo a lanzar mi blog.

Perdiendo la virginidad....

Después de las miles de horas que pasa un informático frente al ordenador y han pasado años hasta que he creado un blog. Más que nada empiezo en esto como juego, como experimento del impacto de las redes sociales, de la facilidad o dificultad de crear un blog, de mantenerlo, de moverse por este mar de blogs que ya existen en la red. Dado que paso mi día con el WebSphere (el que lo conozca y los sufra sabrá que es) el blog hablará muchas veces de WebSphere, de sus problemas, de sus soluciones y los trucos que hemos ido encontrando. Admitiré cualquier pregunta sobre WebSphere y os contaré lo poco o mucho que sepa. Pero no solo eso, el blog tratará de mi, de mis problemas y anécdotas de trabajo, con nuestro peculiar cliente, de las paranoias de todo informático y de la vida en general. De la vida de un informático, esos bichos raros que son como cualquier persona hasta que en un momento dado confiesan....sí, yo también soy informático y lo sufro en silencio.