Hace unas semanas llegando al trabajo enciendo mi compu y veo un correo en donde me indican que una de las interfaces que recibe dictamenes y los envia a un sistema medico NO estaba funcionando... tranquilamente entro al solaris y al ver el log... oh sorpresa!! .. mis threads estaban atorados y un alegre conjunto de mensajes me decia:
Mar 15, 2007 8:44:02 AM CST Error WebLogicServer BEA-000337 ExecuteThread: '14' for queue: 'weblogic.kernel.Default' has been busy fo
r "657" seconds working on the request "Http Request: /WSRecibeST1/recepcionST1.jws"
.. a lo que tranquilamente me di a la tarea de reiniciar mi servidor pensando que con eso se resolveria el problema y una vez levantado revisar que fue lo que paso... je je je ¡oh sorpresa! los alegres mensajes de mis threads seguian saliendo.... y pense "Pus si mi interfaz ha estado operando en casi un año sin problemas..." asi es Tuzo, pero no con el volumen que mandaron esos dias..
El diseño estaba de la siguiente manera:
... el proceso de envío de dictamenes envía un mensaje XML en formato HL7, el servicio de integracion transforma el Xml a un formato de Java y lo envia al endpoint del servicio RMI, ¿sencillo no?, en efecto pero con lo que no contaba, es que RMI necesita dos threads para procesar una peticion.. es decir por un thread atiende y en otro responde.. por lo que en el momento que me mandaron carga, mis threads de ejecucion se terminaron (tenía 15 :D) y RMI no me regresaba la respuesta hasta que no existiera un thread disponible.... asi que entre en un deadlock..
.. pues de alguna manera teniamos que resolver el problema: controlar el numero de peticiones al servicio RMI.
Revisando el libro Enterprise Integration Patterns, se encuentra un patron llamado Competing Consumers, pensando en aplicar este patron para controlar el numero de threds que envia datos al servicio RMI, nos empezo a llegar la luz.
Gustavo y su servilleta pensamos en utilizar la solucion de Aqualogic Service Bus para este caso.... buscando en la documentacion de ALSB encontramos dos cosas A) el patron throttling pattern que permite controlar el grado de concurrencia y B) el concepto WorkManager que define restricciones de carga en threads, asi que nos pusimos manos a la obra y juntando lo anterior mas unas cuantas colas JMS, el resultado quedo en lo siguiente:
... el servicio envia el mensaje a un proxy service, este lo almacena en una cola JMS y libera la conexion, posteriomente un suscriptor consume (de uno en uno) y ejecuta un business service que se encarga de enviar (uno a uno) a la interfaz del EAI para que esta envíe finalmente al servicio RMI. Para garantizar que nuestra solucion funcionaria en produccion, usamos jmeter para enviar 600 mensajes y respondio sin problemas, enviando todos los mensajes en 1 minuto al servicio final.. como veran, con esta solucion es posible controlar el numero de peticiones al servicio final mediante los WorkManagers.
Tambien pueden aplicar el patron Competing Consumers y tendrian el mismo efecto, en algun momento les comentare como este patron nos resolvio un problema al conectarnos con servicios Mainframe.
Pues esta fue la solucion aplicada..
Comentarios y sugerencias son bienvenidos.
Por una integracion mejor, hasta la vista
Tuzo
No hay comentarios.:
Publicar un comentario