Ejemplo 2: Parada automática de un MDB cuando un recurso del sistema deja de estar disponible
Como preparación para el caso en que un recurso del sistema deja de estar disponible, configure el sistema para que detenga de forma automática el bean controlado por mensajes (MDB) después de un número pequeño de errores de mensaje y para alertarle del problema.
Antes de empezar
El destino en el que escucha el MDB debe utilizar un destino de excepción. Este destino de excepción puede ser el valor predeterminado del sistema o uno configurado específicamente para el destino.
- La aplicación empresarial que contiene el MDB.
- El recurso del sistema externo dependiente.
- Un valor de 3 para Umbral de mensaje fallido secuencial. Es el número máximo de errores secuenciales en la entrega de mensajes, tras el cual el MDB se detiene. Esta propiedad se aplica a los conjuntos de mensajes.
- Un valor de 5000 para Retardo entre reintentos de mensaje fallido, es decir, el tiempo en milisegundos antes de que un mensaje que falla esté disponible para ser entregado al MDB. Durante este periodo, se pueden entregar otros mensajes, a menos que Umbral de mensaje fallido secuencial y el valor máximo de simultaneidad estén establecidos en 1.
- Un valor de 5 para Entregas máximas fallidas por mensaje, es decir, el número máximo de intentos fallidos para procesar un mensaje, después del cual el mensaje se envía de su destino previsto al destino de excepción. Esta propiedad se aplica a mensajes individuales.
Acerca de esta tarea
En este escenario, la aplicación empresarial o de nivel empresarial es un sistema de ejecución continuada que utiliza un MDB desplegado para acceder a un recurso del sistema externo.
Si el recurso externo sufre un problema y pasa a estar no disponible, el MDB desplegado no podrá acceder a dicho recurso y, por tanto, la transacción asociada al MDB se retrotraerá y el mensaje msg1 se volverá a poner en la cola.
El mensaje msg1 se oculta durante un retardo de reintento de cinco segundos, establecido en Retardo entre reintentos de mensaje fallido, antes de que pase a estar disponible al MDB.
Mientras tanto, el MDB procesa el siguiente mensaje de la cola, msg2. El recurso externo sigue sin estar disponible, por lo tanto, el proceso de este mensaje también falla. La transacción del mensaje se retrotrae y el mensaje se oculta durante cinco segundos. Se procesa el siguiente mensaje de la cola, msg3, falla y se oculta también.
Cuando el número de mensajes ocultos alcanza el Umbral de mensaje fallido secuencial, el MDB no procesará más mensajes hasta que uno de los mensajes ocultos vuelva a estar disponible.
Cuando caduca el Retardo entre reintentos de mensaje fallido para msg1, msg1 deja de estar oculto y se vuelve a procesar. Dado que el recurso sigue sin estar disponible, el mensaje se vuelve a ocultar. Lo mismo ocurre con los mensajes msg2 y msg3.
Se considera que un mensaje ha fallado cuando se retrotrae una vez menos que el límite de Entregas máximas fallidas por mensaje (cinco veces en este caso de ejemplo). Por lo tanto, cuando msg1 deja de estar oculto por cuarta vez, se retrotrae y se vuelve a ocultar, el valor de número de errores secuenciales se incrementa. Llegado este punto, el mensaje msg2 deja de estar oculto, se retrotrae y se vuelve a ocultar. De forma parecida, msg3 deja de estar oculto, se retrotrae y se vuelve a ocultar. El recuento de errores secuenciales alcanza el Umbral de mensaje fallido secuencial y el MDB se detiene automáticamente. El MBean JCA emite una notificación JMX y una entrada de registro alerta al administrador del sistema que el MDB se ha detenido.