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. Esto se debe a que los mensajes no se encuentran en el nivel de tema, a menos que Service Bus produzca un error interno. 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".

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.

Número máximo de entregas

Hay un límite en el número de intentos de 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 del problema de entrega del mensaje en la cola de mensajes fallidos 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 del motivo del problema de entrega se establece en: TTLExpiredException.

Los mensajes diferidos tampoco 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.

Colas de mensajes fallidos en escenarios ForwardTo o SendVia

Los mensajes se enviarán a la cola de mensajes fallidos de transferencia en las siguientes condiciones:

• 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.

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

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.