En el servidor de aplicaciones Oracle Weblogic existe un parámetro llamado StuckThreadMaxTime que indica el tiempo límite que un proceso o petición (thread) puede estar en ejecución antes de ser considerado atascado (stuck). El valor por defecto es de 600 segundos.
Cuando un thread pasa de 600 segundos en ejecución, el servidor genera una alerta indicando que está en estado stuck junto con el motivo (dump). El proceso sigue su ejecución pero nos advierten que puede haber un problema con el mismo debido al elevado tiempo de ejecución. En circunstancias normales los procesos de la instancia de Weblogic no deberían estar en ejecución 10 minutos así que se requiere una revisión de la situación. Los threads en este estado no pueden ser cancelados/matados, pero sí se pueden recuperar por sí solos si la tarea que están ejecutando llega a finalizar correctamente.
Un número elevado de threads stuck puede provocar como es de esperar, que se llene el Connection Pool y una vez lleno las conexiones entrantes comiencen a rechazarse (una petición entrante = un thread). Aumentando el parámetro max-capacity de threads del Data Source se permitiría dar más tiempo al servicio a recuperarse sin que se llenara el pool de conexiones, aunque esto no soluciona el problema de fondo, que normalmente suele estar a nivel de aplicación, base de datos, problemas de red, etc.
Para la monitorización de estos procesos atascados, podemos hacer uso de SNMP, enviar alertas por correo electrónico o desde la misma administración web de Weblogic (sección Monitoring del servidor correspondiente).
Server > Monitoring > Threads
En la configuración del servidor, también podemos establecer monitorización reactiva automática. En la sección «Overload» de «Configuration» se puede establecer que al llegar a un número concreto de Stuck Threads se tome alguna acción: parar la instancia o reiniciarla, por ejemplo. Estos son los dos parámetros a configurar:
Configuration > Overload
Stuck Thread Count = 0
Failure Action: Ignore, take no action
El primer valor a 0 implica no tener en cuenta el número de stuck threads a la hora de ejecutar la Failure Action.
Espero que os haya aclarado un poco el funcionamiento en Weblogic de estos «stuck Threads».