从死信队列重新提交消息 - Azure 服务总线
Resubmitting a message from dead letter queue - Azure Service Bus
我在 Azure 中创建了一个服务总线队列,它运行良好。如果消息没有在默认尝试(10 次)内传递,它会正确地将消息移动到死信队列。
现在,我想将死信队列中的这条消息重新提交回它的来源队列,看看它是否再次起作用。我使用服务总线资源管理器进行了相同的尝试。但它会立即移至死信队列。
是否可以这样做,如果可以,怎么做?
您需要发送具有相同负载的新消息。 ASB 设计不支持消息重新提交。
当您修复并重新提交来自死信队列的消息时,Service Bus Explorer 工具始终会创建原始消息的克隆。它不会有任何不同,因为默认情况下服务总线消息传递不提供任何消息修复和重新提交机制。我建议您调查为什么您的消息在重新提交时最终会出现在死信队列及其克隆中。希望这对您有所帮助!
听起来可能与 ASB 的 "duplicate message detection" 功能有关。
当您在 ServiceBus Explorer 中重新提交消息时,它将克隆该消息,因此新消息将与死信队列中的原始消息具有相同的 ID。
如果您在 queue/topic 上启用了 "Requires Duplicate Detection" 并尝试在 "Duplicate Detection History Time Window" 内重新提交消息,那么消息将立即再次移至死信队列。
如果您想使用服务总线资源管理器重新提交死信消息,那么我认为您必须在 queue/topic 上禁用 "Requires Duplicate Detection"。
它可能是 "duplicate message detection",如 Peter Berggreen 所示,或者如果您直接将 BrokeredMessage 从死信队列移动到实时队列,那么 DeliveryCount 仍将处于最大值并且它会return 到死信队列。
将 BrokeredMessage 从死信队列中拉出,使用 GetBody() 获取内容,使用该数据创建新的 BrokeredMessage 并将其发送到队列。您可以安全地执行此操作,方法是使用 peek 从死信队列中获取消息内容,然后在从死信队列中删除消息之前将新消息发送到实时队列。这样,如果由于某种原因无法写入实时队列,您就不会丢失任何重要数据。
有了新的 BrokeredMessage,您应该不会遇到 "duplicate message detection" 的问题,DeliveryCount 将重置为零。
尝试去除死信原因
resubmittableMessage.Properties.Remove("DeadLetterReason");
resubmittableMessage.Properties.Remove("DeadLetterErrorDescription");
完整代码
using Microsoft.ServiceBus.Messaging;
using System.Transactions;
namespace ResubmitDeadQueue
{
class Program
{
static void Main(string[] args)
{
var connectionString = "";
var queueName = "";
var queue = QueueClient.CreateFromConnectionString(connectionString, QueueClient.FormatDeadLetterPath(queueName), ReceiveMode.PeekLock);
BrokeredMessage originalMessage
;
var client = QueueClient.CreateFromConnectionString(connectionString, queueName);
do
{
originalMessage = queue.Receive();
if (originalMessage != null)
{
using (var scope = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled))
{
// Create new message
var resubmittableMessage = originalMessage.Clone();
// Remove dead letter reason and description
resubmittableMessage.Properties.Remove("DeadLetterReason");
resubmittableMessage.Properties.Remove("DeadLetterErrorDescription");
// Resend cloned DLQ message and complete original DLQ message
client.Send(resubmittableMessage);
originalMessage.Complete();
// Complete transaction
scope.Complete();
}
}
} while (originalMessage != null);
}
}
}
感谢这里的一些其他回复!
我们有一批大约 6 万条消息,需要从死信队列中重新处理。通过 Service Bus Explorer 查看和发回消息每从我的机器发送 1k 条消息大约需要 6 分钟。我通过为 DLQ 消息设置转发规则到另一个队列并从那里自动将其转发到原始队列解决了这个问题。对于所有 60k 条消息,此解决方案大约需要 30 秒。
我们经常需要重新提交消息。 @Baglay-Vyacheslav 的回答帮了大忙。我粘贴了一些更新的 C# 代码,适用于最新的 Azure.Messaging.ServiceBus Nuget 包。
quicker/easier 可以在 queues/topics/subscribers 上处理 DLQ。
using Azure.Messaging.ServiceBus;
using System.Collections.Generic;
using System.Threading.Tasks;
using NLog;
namespace ServiceBus.Tools
{
class TransferDeadLetterMessages
{
// https://github.com/Azure/azure-sdk-for-net/blob/Azure.Messaging.ServiceBus_7.2.1/sdk/servicebus/Azure.Messaging.ServiceBus/README.md
private static Logger logger = LogManager.GetCurrentClassLogger();
private static ServiceBusClient client;
private static ServiceBusSender sender;
public static async Task ProcessTopicAsync(string connectionString, string topicName, string subscriberName, int fetchCount = 10)
{
try
{
client = new ServiceBusClient(connectionString);
sender = client.CreateSender(topicName);
ServiceBusReceiver dlqReceiver = client.CreateReceiver(topicName, subscriberName, new ServiceBusReceiverOptions
{
SubQueue = SubQueue.DeadLetter,
ReceiveMode = ServiceBusReceiveMode.PeekLock
});
await ProcessDeadLetterMessagesAsync($"topic: {topicName} -> subscriber: {subscriberName}", fetchCount, sender, dlqReceiver);
}
catch (Azure.Messaging.ServiceBus.ServiceBusException ex)
{
if (ex.Reason == Azure.Messaging.ServiceBus.ServiceBusFailureReason.MessagingEntityNotFound)
{
logger.Error(ex, $"Topic:Subscriber '{topicName}:{subscriberName}' not found. Check that the name provided is correct.");
}
else
{
throw;
}
}
finally
{
await sender.CloseAsync();
await client.DisposeAsync();
}
}
public static async Task ProcessQueueAsync(string connectionString, string queueName, int fetchCount = 10)
{
try
{
client = new ServiceBusClient(connectionString);
sender = client.CreateSender(queueName);
ServiceBusReceiver dlqReceiver = client.CreateReceiver(queueName, new ServiceBusReceiverOptions
{
SubQueue = SubQueue.DeadLetter,
ReceiveMode = ServiceBusReceiveMode.PeekLock
});
await ProcessDeadLetterMessagesAsync($"queue: {queueName}", fetchCount, sender, dlqReceiver);
}
catch (Azure.Messaging.ServiceBus.ServiceBusException ex)
{
if (ex.Reason == Azure.Messaging.ServiceBus.ServiceBusFailureReason.MessagingEntityNotFound)
{
logger.Error(ex, $"Queue '{queueName}' not found. Check that the name provided is correct.");
}
else
{
throw;
}
}
finally
{
await sender.CloseAsync();
await client.DisposeAsync();
}
}
private static async Task ProcessDeadLetterMessagesAsync(string source, int fetchCount, ServiceBusSender sender, ServiceBusReceiver dlqReceiver)
{
var wait = new System.TimeSpan(0, 0, 10);
logger.Info($"fetching messages ({wait.TotalSeconds} seconds retrieval timeout)");
logger.Info(source);
IReadOnlyList<ServiceBusReceivedMessage> dlqMessages = await dlqReceiver.ReceiveMessagesAsync(fetchCount, wait);
logger.Info($"dl-count: {dlqMessages.Count}");
int i = 1;
foreach (var dlqMessage in dlqMessages)
{
logger.Info($"start processing message {i}");
logger.Info($"dl-message-dead-letter-message-id: {dlqMessage.MessageId}");
logger.Info($"dl-message-dead-letter-reason: {dlqMessage.DeadLetterReason}");
logger.Info($"dl-message-dead-letter-error-description: {dlqMessage.DeadLetterErrorDescription}");
ServiceBusMessage resubmittableMessage = new ServiceBusMessage(dlqMessage);
await sender.SendMessageAsync(resubmittableMessage);
await dlqReceiver.CompleteMessageAsync(dlqMessage);
logger.Info($"finished processing message {i}");
logger.Info("--------------------------------------------------------------------------------------");
i++;
}
await dlqReceiver.CloseAsync();
logger.Info($"finished");
}
}
}
我在 Azure 中创建了一个服务总线队列,它运行良好。如果消息没有在默认尝试(10 次)内传递,它会正确地将消息移动到死信队列。
现在,我想将死信队列中的这条消息重新提交回它的来源队列,看看它是否再次起作用。我使用服务总线资源管理器进行了相同的尝试。但它会立即移至死信队列。
是否可以这样做,如果可以,怎么做?
您需要发送具有相同负载的新消息。 ASB 设计不支持消息重新提交。
当您修复并重新提交来自死信队列的消息时,Service Bus Explorer 工具始终会创建原始消息的克隆。它不会有任何不同,因为默认情况下服务总线消息传递不提供任何消息修复和重新提交机制。我建议您调查为什么您的消息在重新提交时最终会出现在死信队列及其克隆中。希望这对您有所帮助!
听起来可能与 ASB 的 "duplicate message detection" 功能有关。
当您在 ServiceBus Explorer 中重新提交消息时,它将克隆该消息,因此新消息将与死信队列中的原始消息具有相同的 ID。
如果您在 queue/topic 上启用了 "Requires Duplicate Detection" 并尝试在 "Duplicate Detection History Time Window" 内重新提交消息,那么消息将立即再次移至死信队列。
如果您想使用服务总线资源管理器重新提交死信消息,那么我认为您必须在 queue/topic 上禁用 "Requires Duplicate Detection"。
它可能是 "duplicate message detection",如 Peter Berggreen 所示,或者如果您直接将 BrokeredMessage 从死信队列移动到实时队列,那么 DeliveryCount 仍将处于最大值并且它会return 到死信队列。
将 BrokeredMessage 从死信队列中拉出,使用 GetBody() 获取内容,使用该数据创建新的 BrokeredMessage 并将其发送到队列。您可以安全地执行此操作,方法是使用 peek 从死信队列中获取消息内容,然后在从死信队列中删除消息之前将新消息发送到实时队列。这样,如果由于某种原因无法写入实时队列,您就不会丢失任何重要数据。
有了新的 BrokeredMessage,您应该不会遇到 "duplicate message detection" 的问题,DeliveryCount 将重置为零。
尝试去除死信原因
resubmittableMessage.Properties.Remove("DeadLetterReason");
resubmittableMessage.Properties.Remove("DeadLetterErrorDescription");
完整代码
using Microsoft.ServiceBus.Messaging;
using System.Transactions;
namespace ResubmitDeadQueue
{
class Program
{
static void Main(string[] args)
{
var connectionString = "";
var queueName = "";
var queue = QueueClient.CreateFromConnectionString(connectionString, QueueClient.FormatDeadLetterPath(queueName), ReceiveMode.PeekLock);
BrokeredMessage originalMessage
;
var client = QueueClient.CreateFromConnectionString(connectionString, queueName);
do
{
originalMessage = queue.Receive();
if (originalMessage != null)
{
using (var scope = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled))
{
// Create new message
var resubmittableMessage = originalMessage.Clone();
// Remove dead letter reason and description
resubmittableMessage.Properties.Remove("DeadLetterReason");
resubmittableMessage.Properties.Remove("DeadLetterErrorDescription");
// Resend cloned DLQ message and complete original DLQ message
client.Send(resubmittableMessage);
originalMessage.Complete();
// Complete transaction
scope.Complete();
}
}
} while (originalMessage != null);
}
}
}
感谢这里的一些其他回复!
我们有一批大约 6 万条消息,需要从死信队列中重新处理。通过 Service Bus Explorer 查看和发回消息每从我的机器发送 1k 条消息大约需要 6 分钟。我通过为 DLQ 消息设置转发规则到另一个队列并从那里自动将其转发到原始队列解决了这个问题。对于所有 60k 条消息,此解决方案大约需要 30 秒。
我们经常需要重新提交消息。 @Baglay-Vyacheslav 的回答帮了大忙。我粘贴了一些更新的 C# 代码,适用于最新的 Azure.Messaging.ServiceBus Nuget 包。
quicker/easier 可以在 queues/topics/subscribers 上处理 DLQ。
using Azure.Messaging.ServiceBus;
using System.Collections.Generic;
using System.Threading.Tasks;
using NLog;
namespace ServiceBus.Tools
{
class TransferDeadLetterMessages
{
// https://github.com/Azure/azure-sdk-for-net/blob/Azure.Messaging.ServiceBus_7.2.1/sdk/servicebus/Azure.Messaging.ServiceBus/README.md
private static Logger logger = LogManager.GetCurrentClassLogger();
private static ServiceBusClient client;
private static ServiceBusSender sender;
public static async Task ProcessTopicAsync(string connectionString, string topicName, string subscriberName, int fetchCount = 10)
{
try
{
client = new ServiceBusClient(connectionString);
sender = client.CreateSender(topicName);
ServiceBusReceiver dlqReceiver = client.CreateReceiver(topicName, subscriberName, new ServiceBusReceiverOptions
{
SubQueue = SubQueue.DeadLetter,
ReceiveMode = ServiceBusReceiveMode.PeekLock
});
await ProcessDeadLetterMessagesAsync($"topic: {topicName} -> subscriber: {subscriberName}", fetchCount, sender, dlqReceiver);
}
catch (Azure.Messaging.ServiceBus.ServiceBusException ex)
{
if (ex.Reason == Azure.Messaging.ServiceBus.ServiceBusFailureReason.MessagingEntityNotFound)
{
logger.Error(ex, $"Topic:Subscriber '{topicName}:{subscriberName}' not found. Check that the name provided is correct.");
}
else
{
throw;
}
}
finally
{
await sender.CloseAsync();
await client.DisposeAsync();
}
}
public static async Task ProcessQueueAsync(string connectionString, string queueName, int fetchCount = 10)
{
try
{
client = new ServiceBusClient(connectionString);
sender = client.CreateSender(queueName);
ServiceBusReceiver dlqReceiver = client.CreateReceiver(queueName, new ServiceBusReceiverOptions
{
SubQueue = SubQueue.DeadLetter,
ReceiveMode = ServiceBusReceiveMode.PeekLock
});
await ProcessDeadLetterMessagesAsync($"queue: {queueName}", fetchCount, sender, dlqReceiver);
}
catch (Azure.Messaging.ServiceBus.ServiceBusException ex)
{
if (ex.Reason == Azure.Messaging.ServiceBus.ServiceBusFailureReason.MessagingEntityNotFound)
{
logger.Error(ex, $"Queue '{queueName}' not found. Check that the name provided is correct.");
}
else
{
throw;
}
}
finally
{
await sender.CloseAsync();
await client.DisposeAsync();
}
}
private static async Task ProcessDeadLetterMessagesAsync(string source, int fetchCount, ServiceBusSender sender, ServiceBusReceiver dlqReceiver)
{
var wait = new System.TimeSpan(0, 0, 10);
logger.Info($"fetching messages ({wait.TotalSeconds} seconds retrieval timeout)");
logger.Info(source);
IReadOnlyList<ServiceBusReceivedMessage> dlqMessages = await dlqReceiver.ReceiveMessagesAsync(fetchCount, wait);
logger.Info($"dl-count: {dlqMessages.Count}");
int i = 1;
foreach (var dlqMessage in dlqMessages)
{
logger.Info($"start processing message {i}");
logger.Info($"dl-message-dead-letter-message-id: {dlqMessage.MessageId}");
logger.Info($"dl-message-dead-letter-reason: {dlqMessage.DeadLetterReason}");
logger.Info($"dl-message-dead-letter-error-description: {dlqMessage.DeadLetterErrorDescription}");
ServiceBusMessage resubmittableMessage = new ServiceBusMessage(dlqMessage);
await sender.SendMessageAsync(resubmittableMessage);
await dlqReceiver.CompleteMessageAsync(dlqMessage);
logger.Info($"finished processing message {i}");
logger.Info("--------------------------------------------------------------------------------------");
i++;
}
await dlqReceiver.CloseAsync();
logger.Info($"finished");
}
}
}