So I have an azure function acting as a queue trigger that calls an internally hosted API.
There doesn't seem to be a definitive answer online on how to handle a message that could not be processed due to issues other than being poisonous.
An example:
My message is received and the function attempts to call the API. The message payload is correct and could be handled however the API/service is down for whatever reason (this time will likely be upwards of 10 minutes). Currently what happens is the message delivery count is reaching its max(10) and then getting pushed to the dead letter queue, which in turn happens for each message after.
I need a way to either not increment the delivery count or reset it upon reaching max. Alternatively I could abandon the peek lock on the message without increment the delivery count as I want to stop processing any message on the queue until the API/service is back up and running. This way I would ensure that all messages that can be processed will be and will not fall on the dead letter because of connection issues between services.
Any ideas on how to achieve this?
答案 0 :(得分：1)
目前发生的情况是消息传递计数达到其最大值（10），然后被推送到死信队列，而后面的每个消息都会发生这种情况。
正如此document说明超过MaxDeliveryCount ：
队列和订阅具有QueueDescription.MaxDeliveryCount / SubscriptionDescription.MaxDeliveryCount设置; 默认值为10 。每当消息在锁（ReceiveMode.PeekLock）下传递，但已被明确放弃或锁已过期时，消息的BrokeredMessage.DeliveryCount将递增。当DeliveryCount超过MaxDeliveryCount时，消息将移动到DLQ，指定“MaxDeliveryCountExceeded```原因代码。
无法关闭此行为，但MaxDeliveryCount可以设置为非常大的数字。
根据您的要求，我认为您可以按照以下方法实现您的目的：
用于接收ReceiveMode.PeekLock
下的消息您可以在＆＃34; SETTINGS＆gt;下指定1到2147483647之间的最大交货数量。属性＆＃34; Azure门户上的服务总线队列。
用于接收ReceiveMode.ReceiveAndDelete
当您的API /服务关闭时，您可以try-catch例外，然后您可以将邮件重新发送到您的队列。