通过使用Azure服务总线主题和订阅,我能够在两个系统之间传递消息。但有时,我会遇到锁过期的异常。如何避免?
异常-消息处理程序遇到异常Microsoft.Azure.ServiceBus.MessageLockLostException:提供的锁无效。锁定过期,或者消息已从队列中删除。
下面是代码:
static async Task MainAsync()
{
TokenProvider tokenProvider = TokenProvider.CreateManagedIdentityTokenProvider();
subscriptionClient = new SubscriptionClient(serviceBusNamespace, topicName, subscriptionName,
tokenProvider, receiveMode: ReceiveMode.PeekLock);
// Register subscription message handler and receive messages in a loop
RegisterOnMessageHandlerAndReceiveMessages();
Console.Read();
await subscriptionClient.CloseAsync();
}
static void RegisterOnMessageHandlerAndReceiveMessages()
{
var messageHandlerOptions = new MessageHandlerOptions(ExceptionReceivedHandler)
{
MaxConcurrentCalls = 1,
AutoComplete = false
};
// Register the function that processes messages.
subscriptionClient.RegisterMessageHandler(ProcessMessagesAsync, messageHandlerOptions);
}
static async Task ProcessMessagesAsync(Message message, CancellationToken token)
{
// Process the message recieved.
Console.WriteLine($"Received message: SequenceNumber:{message.SystemProperties.SequenceNumber} Body:{Encoding.UTF8.GetString(message.Body)}");
await subscriptionClient.CompleteAsync(message.SystemProperties.LockToken);
}
Lock lost exception通常是一种客户端错误,可能的原因有两种,要么是服务总线端存在问题(利用率高、邻居噪声大等),要么是客户端太忙,无法及时完成请求,或者是某个非常慢的网络。
检查portal中的服务总线度量,并在观察到问题后,查看在此期间是否存在任何内部或服务器繁忙错误。如果不是,那么建议将查看您的客户机应用程序度量,看看在这段时间内是否有任何高利用率(CPU、内存、网络等)可能会在这段时间内导致问题。
如果上面的方法没有帮助,并且仍然更频繁地观察锁丢失错误,那么我建议您在应用程序代码中添加日志记录,以确认完成消息需要多长时间。如果您正在执行任何业务逻辑,那么请记录执行这段代码所花费的时间。日志应该为您提供应用程序正在使用的messageID的详细信息、UTC中的时间帧、消息上获取的锁令牌以及每个语句(业务逻辑)的执行时间。您还可以在CompleteAsync调用之前和之后添加一个计时器,以检查消息标记为已完成需要多少时间。如果您在代码中添加了预取,我也会建议您删除预取。
验证上述细节,如果问题发生在锁定持续时间内,则需要从客户端和服务总线端进行深入的故障排除。一旦您获得了上述信息并在应用程序中添加了更多的日志记录,您可以创建一个支持票据以获得进一步的帮助,或者请向AzCommunity[at]Microsoft[dot]COM发送一封主题行为“attn:mayank”的电子邮件,其中引用了此线程以及您的Azure订阅ID、服务总线名称、队列名称、接收器应用程序详细信息以及异常消息、消息ID、锁定令牌、您观察到问题的单个消息的时间框架。
我正在使用azure服务总线,我得到的锁已过期。 如何我已经实现了锁定1天,但我仍然得到错误 我的代码: 错误: ---日志记录错误---回溯(最近一次通话最后一次): 文件“/test/.env/lib64/python3.6/site packages/azure/servicebus/_servicebus_receiver.py”,第782行,在放弃消息self中_在第415行,用重试(消
我在Azure服务总线中构建了一个支持多队列订阅的服务,但是我正在得到一些奇怪的行为。 我的subscription singleton类有一个如下所示的方法: 其思想是,您为特定类型的消息订阅Azure Service Bus,该消息直接对应于队列。在订阅中,传入一个委托以了解如何处理消息。 谁能告诉我,我需要做什么不同的,以确保消费者拥有的消息,直到完成?
我有点困惑,试图确定如何窥视锁的工作在服务总线。特别是,我使用Microsoft.Azure.ServiceBus和Azure函数以及ServiceBustrigger。 据我所知,消息被锁定的时间设置在队列本身上,默认值为30秒,但也可以设置在任何地方,最多为5分钟。 当从队列中窥视到一条消息时,这个锁就会启动。 我还有的问题是 是否存在maxAutoRenewDuration可以设置的限制。我
我有一个windows服务,它侦听Azure服务总线队列消息,以便从我的WebApi应用程序分发处理。此外,我还需要处理重复性任务(每晚/每周),我认为最好使用相同的系统来处理这些任务。 例如,假设我有一个“CleanupDb”队列,每天午夜删除过时的DB节点: 理论上这应该行得通,但我觉得我错过了一个更明显的处理方法。有没有更好的办法?
我在Azure中托管了两个云服务辅助角色,一个使用NServiceBus(Azure服务总线传输)消耗消息,另一个生成消息。 昨天,我部署了一个新版本的生产者工作者角色,而队列中仍然有大量消息,因为我们正在处理早上遗留下来的大量消息。当生产者启动时,它似乎已经清空(或者可能重新创建)队列,许多重要的生产消息丢失。这似乎很奇怪,但日志显示,大约在生产者角色启动时,消费者没有处理进一步的消息,我们知道
我正在使用带有.NET核心的Azure服务总线 在我们的应用程序中,我们正在向服务总线发送会话消息。每当我们收到带有session-Id的取消请求时,我们需要删除/删除/完成带有该特定sessionId的消息,而不需要进行任何进一步的处理 但我得到了错误-请求的会话'session-name'不能被接受。它可能被另一个接收器锁定。