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 permitir que un usuario corrija los problemas y vuelva a enviar el mensaje.

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 operaciones normales, como la entrega de peek-lock, las operaciones de recepción y eliminación y transaccional.

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.

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

En .NET, puede usar el método FormatDeadLetterPath.

QueueClient.FormatDeadLetterPath(queuePath)
SubscriptionClient.FormatDeadLetterPath(topicPath, subscriptionName)

Recuento de mensajes fallidos

La obtención del recuento de mensajes en la cola de mensajes fallidos en el nivel de tema no es aplicable porque los mensajes no se sitúan a nivel de 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".

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	La cuota de tamaño de este flujo superó el límite.
TTLExpiredException	El mensaje expiró y se consideró fallido. Consulte la sección Período de vida para ver los detalles.
Session ID is null.	La entidad habilitada por sesión no permite un mensaje cuyo identificador de sesión es null.
MaxTransferHopCountExceeded	El número máximo de saltos permitidos al reenviar entre colas superó el límite. 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.

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.

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. Cada vez que se entrega un mensaje bajo un bloqueo de inspección, pero se abandona explícitamente o el bloqueo ha expirado, se incrementa el recuento de entregas del mensaje. 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.

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 tenga tipos de mensajes que se envían al tema, que no tienen suscriptores, ya que esto puede dar lugar a una gran carga de mensajes DLQ. Por lo tanto, asegúrese de que todos los mensajes enviados al tema tengan al menos una suscripción coincidente.

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.

En .NET, se puede realizar mediante una llamada 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 puede resultar que algunos mensajes superen el límite de cuota de 256 KB para el nivel estándar de Azure Service Bus. Puede actualizar el espacio de nombres de Service Bus desde el nivel estándar al nivel Premium para tener cuotas y límites más altos.

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á deshabilitada, el mensaje se envía a la cola de mensajes fallidos de transferencia (TDLQ) de la cola de origen.
• 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.

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

Una vez que resuelva el problema que provocó que el mensaje se enviara a la cola o al tema, puede volver a enviarlo a la cola o al tema para que se procese de nuevo.

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 que puedan solucionar los errores de procesamiento de los tipos de mensajes, desde qué colas de origen y por qué motivos, a la vez que pueden volver a enviar lotes de mensajes que se van a volver a procesar. Las herramientas como ServicePulse con NServiceBus proporcionan estas funcionalidades.

Contenido relacionado

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.