JMS en WebLogic: componentes, activo-activo y persistencia de mensajes

Esta entrada resume, de forma sencilla, dos dudas habituales cuando se trabaja con WebLogic JMS: qué función cumple cada pieza de la configuración y qué ocurre con los mensajes cuando se usan colas distribuidas y distintos tipos de persistent store.

1. ¿Para qué sirve cada componente JMS en WebLogic?

En WebLogic JMS conviene separar dos mundos: la configuración lógica y la infraestructura física de ejecución.

OSB usa una Connection Factory y una cola por JNDI
        |
        v
JMS Module define qué recursos JMS existen
        |
        v
Subdeployment indica en qué JMS Server vive cada recurso
        |
        v
JMS Server ejecuta físicamente la cola
        |
        v
Store guarda mensajes persistentes
        |
        v
Migratable Target permite mover ese JMS Server/store a otro managed server

Managed Server

Un Managed Server es una JVM de WebLogic. Es el proceso real donde se ejecutan aplicaciones y servicios. En un cluster JMS puede haber varios managed servers, por ejemplo:

Cluster_MensajeriaJMS
  ├── My_nodeJMS1
  └── My_nodeJMS2

La analogía sencilla: el managed server es el edificio.

JMS Server

Un JMS Server es el contenedor físico de colas y tópicos JMS dentro de WebLogic. No es una máquina, sino un servicio JMS que corre dentro de un managed server.

My_nodeJMS1
  └── AJMSServer1

My_nodeJMS2
  └── AJMSServer2

La analogía sencilla: el JMS Server es el almacén dentro del edificio.

Store

El Store es donde WebLogic guarda los mensajes persistentes. Puede ser un File Store o un JDBC Store.

AJMSServer1 -> APersistentStore1
AJMSServer2 -> APersistentStore2

La analogía sencilla: el store es la caja fuerte o el disco donde se guardan los mensajes que todavía no se han entregado.

JMS Module

Un JMS Module es un fichero de configuración que contiene recursos JMS: connection factories, colas, colas distribuidas, tópicos, templates y cuotas.

AJMSModule
BJMSModule
SystemModuleJmsAcme
SystemModule-OCS

La analogía sencilla: el JMS Module es el catálogo. Dice qué recursos existen, pero no es el sitio físico donde se procesan los mensajes.

Connection Factory

La Connection Factory es la puerta de entrada que usa el cliente para conectarse a JMS. Si el flujo es:

Aplicación Java -> OSB -> JMS

entonces normalmente OSB hace lookup por JNDI de una connection factory y de una cola.

ConnectionFactoryA
ConnectionFactoryB
ConnectionFactoryAcme

La analogía sencilla: la connection factory es la puerta por la que OSB entra al sistema JMS.

Cola standalone

Una cola standalone vive en un único JMS Server. Aunque el módulo esté targeteado al cluster, la cola puede estar realmente ejecutándose solo en un managed server.

Cola A_X
  -> ASubdeployment
       -> AJMSServer1

En ese caso, el segundo JMS Server existe, pero esa cola concreta no lo utiliza.

Uniform Distributed Queue

Una Uniform Distributed Queue, o UDD, es una cola lógica con varios miembros físicos. Desde OSB puede verse como una sola cola JNDI, pero por debajo WebLogic tiene un miembro en cada JMS Server targeteado.

jms/A_X
  ├── A_X@AJMSServer1
  └── A_X@AJMSServer2

La analogía sencilla: una cola standalone es un buzón en un único almacén; una UDD es un buzón lógico repartido en varios almacenes.

Subdeployment

El Subdeployment indica dónde vive un grupo de recursos JMS. Es una de las piezas más importantes y también una de las más confusas.

Situación concentrada en un solo JMS Server:

AJMSModule
  ASubdeployment
    Target: AJMSServer1

Situación distribuida:

AJMSModule
  ASubdeployment
    Targets:
      AJMSServer1
      AJMSServer2

Importante: para que una cola use dos JMS Servers, no basta con tocar el subdeployment. La cola debe ser una cola distribuida. Una cola standalone no vive simultáneamente en dos JMS Servers.

Migratable Target

El Migratable Target sirve para alta disponibilidad. Permite mover un JMS Server, junto con su store, de un managed server a otro en caso de fallo o mantenimiento.

AJMSServer1
  -> AMigratableTarget1
       Preferred server: My_nodeJMS1
       Candidate server: My_nodeJMS2

La analogía sencilla: el migratable target es el carro con ruedas que permite mover el almacén de un edificio a otro.

Activo-pasivo frente a activo-activo

En una configuración activo-pasivo, la cola real vive en un único JMS Server. Si ese JMS Server falla, puede migrarse a otro nodo, pero sigue existiendo una sola instancia activa de la cola.

Activo-pasivo:

My_nodeJMS1
  AJMSServer1
    Cola A_X

My_nodeJMS2
  AJMSServer2
    sin miembro de A_X

En una configuración activo-activo con UDD, la cola lógica tiene miembros en ambos JMS Servers.

Activo-activo:

My_nodeJMS1
  AJMSServer1
    A_X miembro 1

My_nodeJMS2
  AJMSServer2
    A_X miembro 2

La idea clave es esta:

JMS Module        = qué recursos existen
Subdeployment     = dónde viven esos recursos
JMS Server        = quién ejecuta físicamente las colas
Store             = dónde se guardan los mensajes persistentes
Migratable Target = cómo se mueve un JMS Server si falla un nodo
UDD               = cómo se consigue activo-activo para una cola

Por tanto, para conseguir activo-activo no basta con tener dos managed servers, dos JMS Servers y dos stores. También hay que convertir las colas standalone en Uniform Distributed Queues y targetearlas a ambos JMS Servers mediante el subdeployment.

¿Qué cambia si hay Unit-of-Order?

Unit-of-Order sirve para mantener el orden de procesamiento de un conjunto de mensajes. Si cada cliente, contrato o entidad tiene su propia clave de orden, WebLogic puede repartir esas claves entre miembros de la cola distribuida.

Buen escenario:

Unit-of-Order = cliente_001 -> miembro 1
Unit-of-Order = cliente_002 -> miembro 2
Unit-of-Order = cliente_003 -> miembro 1

Pero si todos los mensajes usan la misma Unit-of-Order, por ejemplo 1, WebLogic puede concentrarlos en un único miembro físico para respetar el orden.

Escenario problemático:

Todos los mensajes usan Unit-of-Order = 1

Resultado posible:
  cola distribuida configurada en activo-activo,
  pero tráfico real concentrado en un solo miembro.

Es decir, la UDD puede estar bien configurada, pero el balanceo real puede verse limitado por la necesidad de conservar el orden.

2. ¿Qué pasa con los mensajes si una cola distribuida usa File Store, JDBC Store o NAS compartido?

La idea principal es que una cola distribuida mejora la continuidad del servicio, pero no replica automáticamente cada mensaje en todos los nodos.

UDD / cola distribuida = continuidad parcial de servicio
Store                  = conservación de mensajes persistentes
Migratable Target      = recuperación del JMS Server caído en otro nodo
Tipo de storage        = posibilidad real de recuperar el store desde otro nodo

Una UDD no replica mensajes entre stores

Una Uniform Distributed Queue no significa que cada mensaje esté copiado en todos los nodos. Significa que la cola lógica tiene varios miembros físicos y WebLogic reparte los mensajes entre ellos.

Mensaje 1 -> A_X@AJMSServer1 -> Store1
Mensaje 2 -> A_X@AJMSServer2 -> Store2
Mensaje 3 -> A_X@AJMSServer1 -> Store1
Mensaje 4 -> A_X@AJMSServer2 -> Store2

Si cae AJMSServer1, los mensajes que estaban en Store1 no aparecen mágicamente en Store2. Para recuperarlos, debe volver el JMS Server propietario o debe migrar a otro managed server con acceso al mismo store.

File Store local

Si el store es de tipo filesystem y está en disco local del nodo caído, la caída de un managed server no tiene por qué provocar caída total del servicio si hay una UDD y otro miembro sigue vivo.

My_nodeJMS1 cae
  AJMSServer1 no disponible
  Store1 no accesible

My_nodeJMS2 sigue vivo
  AJMSServer2 sigue procesando
  Store2 sigue accesible

Pero los mensajes persistentes que estaban en el file store local del nodo caído quedan no disponibles hasta que vuelva ese nodo o se recupere ese store.

No es correcto decir automáticamente que se pierden mensajes. Si el disco local sigue intacto, los mensajes deberían poder recuperarse cuando vuelva a arrancar el JMS Server propietario. El riesgo real aparece si se pierde o corrompe el disco local, o si el JMS Server no puede volver a acceder a su store.

File Store local:

Ventaja:
  simple y rápido.

Problema:
  los mensajes quedan atados al nodo/disco donde está el store.

Riesgo:
  si se pierde el disco local, pueden perderse mensajes persistentes.

JDBC Store

Con JDBC Store, los mensajes persistentes se guardan en base de datos. Esto evita que los mensajes dependan del disco local del managed server.

AJMSServer1
  -> JDBC Store
       -> Base de datos

Si el JMS Server puede migrar a otro managed server y la base de datos sigue disponible, el nuevo nodo puede recuperar el mismo store JDBC.

Aun así, no conviene decir que con JDBC Store “nunca hay pérdida de mensajes”. Depende de que los mensajes sean persistentes, de que las transacciones hayan hecho commit correctamente, de que la base de datos esté disponible y de que el datasource esté bien configurado.

JDBC Store + base de datos en alta disponibilidad:
  buena opción para recuperar mensajes persistentes desde otro nodo.

JDBC Store + base de datos sin alta disponibilidad:
  el punto único de fallo puede pasar a ser la base de datos.

File Store en NAS o SAN compartido

Un File Store en NAS o SAN compartido puede funcionar como solución de alta disponibilidad si todos los managed servers candidatos pueden acceder al mismo directorio de store.

My_nodeJMS1
  AJMSServer1
    FileStore1 -> /nas/jms/AJMSServer1

My_nodeJMS2
  puede arrancar AJMSServer1 migrado
    usando el mismo /nas/jms/AJMSServer1

En ese caso, si cae My_nodeJMS1, se puede migrar AJMSServer1 a My_nodeJMS2 y abrir el mismo file store compartido. Así se pueden recuperar los mensajes persistentes del miembro caído.

Pero hay una condición importante: el NAS o SAN debe ser fiable para este uso. No basta con que el directorio “se vea” desde ambos nodos. Debe ofrecer garantías correctas de escritura síncrona, locking, consistencia y recuperación ante fallos.

File Store en NAS/SAN compartido:

Ventaja:
  permite que un JMS Server migrado acceda al mismo store desde otro nodo.

Condición:
  el storage compartido debe ser fiable y adecuado para stores transaccionales.

Riesgo:
  un NAS mal configurado puede ser más peligroso que un JDBC Store.

Tabla resumen

Configuración	Servicio si cae un nodo	Mensajes del nodo caído	Riesgo principal
UDD + File Store local	El otro miembro puede seguir funcionando	No disponibles hasta recuperar el nodo/store	Pérdida si se pierde el disco local
UDD + File Store local + migratable target sin storage compartido	El otro miembro puede seguir funcionando	No recuperables desde otro nodo salvo scripts o recuperación manual	El store sigue atado al nodo original
UDD + File Store en NAS/SAN + migratable target	El otro miembro sigue funcionando y el JMS Server caído puede migrar	Recuperables si el storage compartido está sano	NAS/SAN mal configurado o no transaccionalmente seguro
UDD + JDBC Store + base de datos HA	El otro miembro sigue funcionando y el JMS Server caído puede migrar	Recuperables desde la base de datos	Configuración incorrecta de BD/datasource/transacciones
UDD + JDBC Store + base de datos sin HA	Depende de que la base de datos siga disponible	Dependen de la base de datos	El punto único de fallo pasa a ser la BD

Conclusión práctica

La frase más importante es esta:

UDD evita la caída total de servicio.
El store conserva los mensajes persistentes.
El migratable target permite mover el JMS Server a otro nodo.
JDBC Store o File Store compartido permiten recuperar mensajes desde otro nodo.

Por tanto, si el requisito es solo repartir carga, una UDD es la pieza clave. Si además el requisito es recuperar mensajes persistentes aunque caiga un nodo, entonces hay que cuidar mucho el store y la migración.

Para pruebas o integración:
  UDD + stores actuales puede servir para validar activo-activo.

Para producción con mensajes críticos:
  UDD
  + un JMS Server por nodo
  + un store por JMS Server
  + migratable targets
  + JDBC Store sobre BD HA

  o bien:

  UDD
  + un JMS Server por nodo
  + un store por JMS Server
  + migratable targets
  + File Stores en NAS/SAN compartido fiable

La pregunta que hay que hacerse no es solo “¿la cola es distribuida?”, sino también:

Si cae el nodo donde estaba un mensaje persistente,
¿otro nodo puede arrancar el mismo JMS Server y acceder al mismo store?

Si la respuesta es sí, hay continuidad de servicio y capacidad de recuperación de mensajes. Si la respuesta es no, la UDD puede mantener vivo el servicio con los miembros supervivientes, pero los mensajes del miembro caído quedarán pendientes de recuperar junto con su store.

Read More