Visão geral das filas de mensagens mortas do Barramento de Serviço

As filas e as assinaturas de tópico do Barramento de Serviço do Azure fornecem uma subfila secundária chamada DLQ (fila de mensagens mortas). A fila de mensagens mortas não precisa ser explicitamente criada e não pode ser excluída ou gerenciada independentemente da entidade principal.

Este artigo descreve as filas de mensagens mortas no Barramento de Serviço. Grande parte da discussão é ilustrada pelo exemplo de Filas de mensagens mortas no GitHub.

A fila de mensagens mortas

A finalidade da fila de mensagens mortas é manter mensagens que não podem ser entregues a nenhum receptor ou mensagens que não puderam ser processadas. As mensagens podem ser removidas da DLQ e inspecionadas. Um aplicativo pode, com a ajuda de um operador, corrigir problemas e reenviar a mensagem, registrar o fato de que houve um erro e tomar uma medida corretiva.

De uma perspectiva de API e protocolo, a DLQ é bem semelhante a qualquer outra fila, com exceção de que essas mensagens podem ser enviadas apenas por meio da operação de mensagens mortas da entidade pai. Além disso, a vida útil não é observada, e você não pode colocar uma mensagem em estado morto na DLQ. A fila de mensagens mortas é totalmente compatível com operações transacionais e de entrega de espiada-bloqueio.

Não há limpeza automática da DLQ. As mensagens permanecem na DLQ até você recuperá-las de lá explicitamente e concluir a mensagem morta.

Contagem de mensagens da DLQ

Não é possível obter a contagem de mensagens da fila de mensagens mortas no nível do tópico. Isso é porque as mensagens não se situam no nível do tópico. Em vez disso, quando um remetente envia uma mensagem a um tópico, a mensagem é encaminhada para as assinaturas do tópico em milissegundos e, portanto, não reside mais no nível do tópico. Portanto, você pode ver mensagens na DLQ associada à assinatura do tópico. No exemplo a seguir, Service Bus Explorer mostra que atualmente há 62 mensagens em DLQ para a assinatura "test1".

Você também pode obter a contagem de mensagens DLQ usando o comando da CLI do Azure: az servicebus topic subscription show.

Movendo mensagens para a DLQ

Há várias atividades no Barramento de Serviço que fazem com que as mensagens sejam enviadas por push à DLQ de dentro do próprio mecanismo de mensagens. Um aplicativo também pode explicitamente colocar mensagens na DLQ. As duas propriedades a seguir (motivo de mensagens mortas e descrição de mensagens mortas) são adicionadas às mensagens mortas. Os aplicativos podem definir seus próprios códigos para a propriedade motivo de mensagens mortas, mas o sistema define os valores seguintes.

Motivo da mensagem morta	Descrição de erro da mensagem morta
HeaderSizeExceeded	A cota de tamanho para este fluxo foi excedida.
TTLExpiredException	A mensagem expirou e foi colocada no estado de mensagem morta. Consulte a seção Vida útil para obter detalhes.
A ID da sessão é nula.	A entidade habilitada para sessão não permite uma mensagem cuja identificação de sessão seja nula.
MaxTransferHopCountExceeded	O número máximo de saltos permitidos ao realizar encaminhamento entre filas foi excedido. Esse valor é definido como 4.
MaxDeliveryCountExceeded	A mensagem não pôde ser consumida após as tentativas de entrega máximas. Consulte a seção Contagem de entrega máxima para obter detalhes.

Contagem máxima de entregas

Há um limite para o número de tentativas de entrega de mensagens para filas e assinaturas do Barramento de Serviço. O valor padrão é 10. Sempre que uma mensagem tiver sido entregue em um bloqueio de inspeção, mas tiver sido explicitamente abandonada ou o bloqueio tiver expirado, a contagem da entrega na mensagem é incrementada. Quando a contagem da entrega excede o limite, a mensagem é movida para o DLQ. O motivo das mensagens mortas para a mensagem no DLQ é definido como: MaxDeliveryCountExceeded. Esse comportamento não pode ser desabilitado, mas você pode definir a contagem de entrega máxima para um número alto.

Vida útil

Quando você habilita a mensagem morta em filas ou assinaturas, todas as mensagens que estão expirando são movidas para o DLQ. O código do motivo da mensagem morta é definido como: TTLExpiredException.

As mensagens adiadas não serão limpas e movidas para a fila de mensagens mortas após expirarem. Este comportamento ocorre por design.

Erros ao processar as regras de assinatura

Se você habilitar as mensagens mortas em exceções da avaliação de filtro, todos os erros que ocorrerem durante a execução de uma regra de filtro SQL de uma assinatura serão capturados no DLQ junto a mensagem incorreta. Não use essa opção em um ambiente de produção no qual nem todos os tipos de mensagem têm assinantes.

Mensagens mortas no nível de aplicativo

Além dos recursos de mensagens mortas fornecidas pelo sistema, os aplicativos podem usar a DLQ para rejeitar explicitamente mensagens inaceitáveis. Elas podem incluir mensagens que não puderam ser processadas adequadamente devido a qualquer tipo de problema no sistema, mensagens que mantêm cargas malformadas ou mensagens que falham na autenticação quando algum esquema de segurança no nível de mensagem é usado.

Isso pode ser feito chamando o método ServiceBusReceiver.DeadLetterMessageAsync.

Recomendamos que você inclua o tipo da exceção no DeadLetterReason e o rastreamento de pilha da exceção no DeadLetterDescription, pois isso facilita a solução de problemas, resultando em mensagens mortas. Esteja ciente de que isso poderá fazer com que algumas mensagens excedam o limite de cota de 256 KB da Camada Standard do Barramento de Serviço do Azure, indicando ainda mais que a Camada Premium é a que deve ser usada para os ambientes de produção.

Mensagens mortas em cenários de encaminhamento automático

Mensagens são enviadas para a fila de mensagens mortas sob as seguintes condições:

• Uma mensagem que passe por mais de quatro filas ou tópicos encadeados.
• A fila ou o tópico de destino é desabilitado ou excluído.
• O tópico ou a fila de destino excede o tamanho máximo de entidade.

Mensagens mortas em envio por meio de cenários

• Se a fila de destino ou o tópico estiver desabilitado, a mensagem será enviada para uma fila de mensagens mortas de transferência (TDLQ) da fila de origem.
• Se a fila de destino ou o tópico for excluído, a exceção 404 será gerada.
• Se a fila ou entidade de destino exceder o tamanho da entidade, a mensagem será enviada para um TDLQ da fila de origem.

Caminho para a fila de mensagens mortas

É possível acessar a fila de mensagens mortas usando a seguinte sintaxe:

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

Enviar mensagens mortas para serem reprocessadas

Como pode haver dados comerciais valiosos em mensagens que acabaram na fila de mensagens mortas, é interessante que essas mensagens sejam reprocessadas quando os operadores terminarem de lidar com as circunstâncias que fizeram com que elas fossem consideradas mortas.

Ferramentas como o Azure Service Bus Explorer permitem a movimentação manual de mensagens entre filas e tópicos. Se houver muitas mensagens na fila de mensagens mortas que precisem ser movidas, um código como este poderá ajudar a mover todas elas de uma vez só. Os operadores geralmente preferem contar com uma interface do usuário que permita entender quais tipos de mensagem falharam no processamento, de quais filas de origem elas vieram e quais foram os motivos da falha, podendo reenviar lotes de mensagens a serem reprocessadas. Ferramentas como o ServicePulse com NServiceBus oferecem essas funcionalidades.

Próximas etapas

Consulte Habilitar mensagens mortas para uma fila ou assinatura para saber mais sobre as maneiras diferentes de configurar as mensagens mortas sobre a expiração de mensagens.