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.