Información general de colas de mensajes fallidos de Service Bus

Las colas de Azure Service Bus y las suscripciones a temas proporcionan una subcola secundaria, llamada cola de mensajes fallidos (DLQ). No es necesario crear explícitamente la cola de mensajes fallidos y no se puede eliminar ni administrar independientemente de la entidad principal.

En este artículo se describen las colas de mensajes fallidos de Service Bus. Gran parte de la descripción se muestra en el ejemplo de colas de mensajes fallidos en GitHub.

Cola de mensajes fallidos

La finalidad de la cola de mensajes fallidos es mantener los mensajes que no se pueden entregar a ningún destinatario o los mensajes que no se pudieron procesar. Después, los mensajes se quitan de la cola de mensajes fallidos y se inspeccionan. Una aplicación podría, con ayuda de un operador, corregir los problemas y volver a enviar el mensaje, registrar el hecho de que se produjo un error y llevar a cabo medidas correctivas.

Desde el punto de vista de la API y el protocolo, la cola de mensajes fallidos es muy similar a cualquier otra cola, salvo que los mensajes solo se pueden enviar a través de la operación de mensajes fallidos de la entidad principal. Además, no se observa el período de vida, y no puede tratar como fallido un mensaje desde una cola de mensajes fallidos. La cola de mensajes fallidos es totalmente compatible con las operaciones transaccionales y de entrega de bloqueo de información.

No hay limpieza automática de mensajes fallidos. Los mensajes permanecen en la cola de mensajes fallidos hasta que los recupere explícitamente de dicha cola y complete el mensaje con problemas de entrega.

Recuento de mensajes fallidos

No es posible obtener el número de mensajes de la cola de mensajes fallidos en el nivel de tema. Eso es porque los mensajes no se ubican a nivel del tema. En su lugar, cuando un remitente envía un mensaje a un tema, el mensaje se reenvía a las suscripciones del tema en milisegundos y, por tanto, ya no reside en el nivel de tema. Por lo tanto, puede ver los mensajes en los mensajes fallidos asociados con la suscripción del tema. En el ejemplo siguiente, Service Bus Explorer muestra que hay 62 mensajes actualmente en los mensajes fallidos de la suscripción "test1".

Image showing 62 messages in the dead-letter queue.

También puede obtener el recuento de mensajes fallidos mediante el comando de la CLI de Azure: az servicebus topic subscription show.

Movimiento de mensajes a la cola de mensajes fallidos

Hay varias actividades en Service Bus que provocan que los mensajes se inserten en la cola de mensajes fallidos desde dentro del propio motor de mensajería. Una aplicación también puede mover mensajes explícitamente a la cola de mensajes fallidos. Las dos propiedades siguientes (motivo del problema de entrega y descripción del problema de entrega) se agregan a los mensajes con problemas de entrega. Las aplicaciones pueden definir sus propios códigos para la propiedad de motivo del problema de entrega, pero el sistema establece los valores siguientes.

Motivo del problema de entrega Descripción del error del problema de entrega
HeaderSizeExceeded Se superó la cuota de tamaño de esta transmisión.
TTLExpiredException El mensaje expiró y se consideró fallido. Consulte la sección Período de vida para ver los detalles.
El identificador de sesión es null. La entidad habilitada por sesión no permite un mensaje cuyo identificador de sesión es null.
MaxTransferHopCountExceeded Se ha superado el número máximo de saltos permitidos al reenviar contenido entre colas. Este valor se establece en 4.
MaxDeliveryCountExceeded El mensaje no se pudo usar después de que transcurriera el número máximo de intentos de entrega. Consulte la sección Número máximo de entregas para más información.

Número máximo de entregas

Hay un límite en el número de intentos para entregar mensajes para las colas y suscripciones de Service Bus. El valor predeterminado es 10. Cuando un mensaje se entrega bajo un bloqueo de inspección, pero se abandona explícitamente o el bloqueo expira, el número de entregas del mensaje se incrementa. Cuando el número de entregas supera el límite, el mensaje se mueve a la cola de mensajes fallidos. El motivo de los mensajes fallidos del mensaje en DLQ se establece en: MaxDeliveryCountExceeded. Este comportamiento no se puede deshabilitar, pero puede establecer el número máximo de entregas en un número grande.

Período de vida

Cuando se habilitan los mensajes con problemas de entrega en colas o suscripciones, todos los mensajes que expiran se mueven a la cola de mensajes fallidos. El código de motivo de mensajes fallidos se establece en: TTLExpiredException.

Los mensajes diferidos no se purgarán ni moverán a la cola de mensajes fallidos tras expirar. Este comportamiento es así por diseño.

Errores al procesar reglas de suscripción

Si habilita los mensajes con problemas de entrega en las excepciones de evaluación de filtro, los errores que se producen mientras se ejecuta la regla de filtro SQL de una suscripción se capturan en la cola de mensajes fallidos junto con el mensaje infractor. No use esta opción en un entorno de producción en el que no todos los tipos de mensaje tienen suscriptores.

Mensajes fallidos de nivel de aplicación

Además de las características de mensajes fallidos proporcionadas por el sistema, las aplicaciones pueden usar la cola de mensajes fallidos para rechazar explícitamente mensajes inaceptables. Esto puede incluir mensajes que no se pueden procesar correctamente debido a cualquier tipo de problema del sistema, mensajes que mantienen cargas útiles con un formato incorrecto o mensajes que no superan la autenticación cuando se utiliza algún esquema de seguridad de nivel de mensaje.

Esto se puede hacer llamando al método ServiceBusReceiver.DeadLetterMessageAsync.

Se recomienda incluir el tipo de excepción en DeadLetterReason y el seguimiento de la pila de la excepción en DeadLetterDescription, ya que facilita la solución del problema que provoca que los mensajes sean mensajes fallidos. Tenga en cuenta que esto puede dar lugar a que algunos mensajes superen el límite de cuota de 256 KB para el nivel estándar de Azure Service Bus, lo que indica que el nivel Premium es lo que se debe utilizar para los entornos de producción.

Mensajes fallidos en escenarios de reenvío automático

Los mensajes se envían a la cola de mensajes fallidos en las condiciones siguientes:

  • Un mensaje pasa a través de más de cuatro colas o temas que están encadenados.
  • La cola de destino o el tema se han deshabilitado o eliminado.
  • El tema o la cola de destino superan el tamaño máximo de entidad.

Mensajes fallidos en envío a través de escenarios

  • Si la cola de destino o el tema están deshabilitados, el mensaje se envía a una cola de mensajes fallidos de transferencia (TDLQ) de la cola de origen.
  • Si se elimina la cola o el tema de destino, se genera la excepción 404.
  • Si la cola de destino o la entidad superan el tamaño de la entidad, el mensaje se envía a un TDLQ de la cola de origen.

Ruta de acceso para la cola de mensajes fallidos

Puede tener acceso a la cola de mensajes fallidos mediante la sintaxis siguiente:

<queue path>/$deadletterqueue
<topic path>/Subscriptions/<subscription path>/$deadletterqueue

Envío de mensajes fallidos que se van a volver a procesar

Como puede haber datos empresariales valiosos en los mensajes que terminaron en la cola de mensajes fallidos, es conveniente que esos mensajes se vuelvan a procesar cuando los operadores hayan terminado de lidiar con las circunstancias que provocaron que los mensajes se enviaran.

Herramientas como Azure Service Bus Explorer habilitan el movimiento manual de mensajes entre colas y temas. Si hay muchos mensajes en la cola de mensajes fallidos que deben moverse, el código como este puede ayudar a moverlos a la vez. A menudo, los operadores prefieren tener una interfaz de usuario para poder solucionar los tipos de mensajes que han producido un error en el procesamiento, desde qué colas de origen y por qué motivos, a la vez que puedan volver a enviar lotes de mensajes para volver a procesar. Las herramientas como ServicePulse con NServiceBus proporcionan estas funcionalidades.

Pasos siguientes

Consulte el artículo sobre la habilitación de mensajes fallidos para una cola o suscripción para obtener información sobre las distintas formas de establecer la configuración de los mensajes fallidos cuando expire un mensaje.