From c1e68028cfc5a7cfec927afeca5ff43c3c63794e Mon Sep 17 00:00:00 2001 From: Laila Bougria Date: Mon, 2 Dec 2024 09:23:42 +0000 Subject: [PATCH] Add some more information for users to consider regarding prefetch and locking (#6918) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Update configuration.md * Update transports/azure-service-bus/configuration.md Co-authored-by: Andreas Öhlund --------- Co-authored-by: Andreas Öhlund --- transports/azure-service-bus/configuration.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/transports/azure-service-bus/configuration.md b/transports/azure-service-bus/configuration.md index 2d7b1e982aa..527531f85e4 100644 --- a/transports/azure-service-bus/configuration.md +++ b/transports/azure-service-bus/configuration.md @@ -50,6 +50,7 @@ To disable prefetching, prefetch count should be set to zero. > [!NOTE] > The lock duration for all prefetched messages starts as soon as they are fetched. To avoid `LockLostException`, ensure the lock-renewal duration is longer than the total time it takes to process all prefetched messages (i.e., message handler execution time multiplied by the prefetch count). +> In addition, it's important to consider the endpoint's scaling. If the prefetch count is high, the lock may deprive other endpoint instances of messages, rendering additional endpoint instances unnecessary. ## Lock-renewal @@ -60,4 +61,7 @@ To ensure smooth processing, it is recommended to configuring the `MaxAutoLockRe partial: lockrenewal > [!NOTE] -> Message lock renewal is initiated by client code, not the broker. If the request to renew the lock fails after all the SDK built-in retries (.e.g due to a connection-loss), the lock won't be renewed, and the message will become unlocked and available for processing by competing consumers. Lock renewal should be treated as best-effort and not as a guaranteed operation. +> Message lock renewal is initiated by client code, not the broker. If the request to renew the lock fails after all the SDK built-in retries (e.g., due to connection loss), the lock won't be renewed, and the message will become unlocked and available for processing by competing consumers. Lock renewal should be treated as a best effort, not as a guaranteed operation. + +> [!NOTE] +> If message lock renewal is required, it may be worth checking the duration of the handlers, and see whether these can be optimised. In addition, it may be worth checking whether the prefetch count is too high, considering all messages are locked on peek. This may indicate that too many messages are locked for which the processing exceeds the lock duration.