5
votes

I'm getting a bit confused trying to nail down how peek lock works in Service Bus. In particular I'm using Microsoft.Azure.ServiceBus with Azure Functions and a ServiceBusTrigger.

From what I can make out the time a message gets locked for is set on the queue itself and defaults to 30 seconds though it can be set to be anywhere up to 5 minutes.

When a message is peeked from the queue this lock kicks in.

There is then a setting called maxAutoRenewDuration which when using Azure Functions is set in the host.json file under Extensions:ServiceBus:messageHandlerOptions. This allows the client to automatically request one or more extensions to a lock until the maxAutoRenewDuration is reached. Once you hit this limit a renewal won't be requested and the lock will be released.

Renewals are best effort and can't be guaranteed so ideally you try to come up with a design where messages are typically processed within the lock period specified on the queue.

Have I got this right so far?

Questions I still have are

  1. are there and limits on what maxAutoRenewDuration can be set to. One article I read seemed to suggest that this could be set to whatever I need to ensure my message is processed (link). The Microsoft Documentation though states that the maximum value for this is also limited to 5 minutes (link).

The maxAutoRenewDuration is configurable in host.json, which maps to OnMessageOptions.MaxAutoRenewDuration. The maximum allowed for this setting is 5 minutes according to the Service Bus documentation

Which is correct? I know the default lock duration has a maximum of 5 minutes but it doesn't seem to make sense that this also applies to maxAutoRenewDuration?

  1. I've read about a setting called MaxLockDuration in some articles (e.g. link). Is this just referring to the lock duration set on the queue itself?

  2. Am I missing anything else? Are the lock duration set on the queue and the maxAutoRenewDuration in my code the main things I need to consider when dealing with locks and renewals?

Thanks

Alan

1
Thanks @krishg. It was Sean's use of "MaxLockDuration" in the post I linked to above that was my reason for question 2 above. After reading the link you provided I'm still not clear on whether he is using that to just refer to the lock duration as it is set on the queue itself..? As to question 1 above, your link doesn't give an upper bound on what MaxAutoRenewDuration can be set to (though I get the impression he is siding with the first link I provided [so set it to anything you need] rather than the quote from the Microsoft documentation which says it is limited to 5 mins).Alan
I had time for some testing yesterday and I could certainly set MaxAutoRenewDuration longer than 5 minutes and have it honoured so I'm assuming the quoted Microsoft documentation is wrong on that point.Alan
Posted the answer belowkrishg

1 Answers

1
votes

I understand your confusion. The official doc explanation of maxAutoRenewDuration seems wrong. There is already an open doc issue https://github.com/MicrosoftDocs/azure-docs/issues/62110 and also a reference https://github.com/Azure/azure-functions-host/issues/6500.

To pinpoint your questions:

  • #1: As told above, the there is open doc issue.
  • #2: MaxLockDuration is Service Bus queue side setting which basically signifies that if you peek lock a message from the queue, the message is locked for the consumer for that duration. So, unless you complete your message processing or renew lock within that period, the lock is going to expire.
  • #3: @sean-feldman 's awesome explanation in the thread https://stackoverflow.com/a/60381046/13791953 should answer that.

What it does is extends the message lease with the broker, "re-locking" it for the competing consumer that is currently handling the message. MaxAutoRenewDuration should be set to the "possibly maximum processing time a lease will be required".