NServiceBus.AzureServiceBusTransport Message Lock Renewal

Hi,

We are currently experiencing issues with messages timing out while in the pre-fetch buffer when using using the Nservicebus.AzureServiceBus Transport (NServiceBus.Transport.AzureServiceBus). Is there any way to intercept the incoming message to allow us to discard the message when the lock has timed out or alternatively to renew the message if it hasn’t already timed out (We’ve looked at using an incoming transport message mutator but it doesn’t contain enough info to handle both scenarios). This only seems to happen intermittently so I would prefer not to change the pre-fetch count as 99% of the time the messages in the pre-fetch buffer are processed with no issues.

The underlying SDK will fetch the messages and give it to NServiceBus regardless if the lock duration has expired or not. NServiceBus ASB transport could look at the LockedUntiUtc to determine wherever the message has been unlocked or not, but there’s always a risk of clock skew and that logic be inaccurate.

I would recommend to lower your prefetching count. It sounds the prefetch count is either too aggressive or the concurrency level is not sufficient to deal with the fetched messages.

Hi Sean,

Thanks for the response, much appreciated. I’d prefer not to change the pre-fetch count for the reason stated earlier. Allowing the consumer of the transport library to make the decision to discard/allow the message either by config on the transport or by exposing “LockedUntilUtc” via an incoming header feels like a better solution to me. What do you think?

NServiceBus does not propagate any of the native headers unless they are required for the internal work of the transport. I would suggest raising a feature issue with the use case. You can raise it here: https://github.com/Particular/NServiceBus.Transport.AzureServiceBus

Thanks Sean, I’ll do that now.

1 Like

Anyone interested in the issue, it’s here: https://github.com/Particular/NServiceBus.Transport.AzureServiceBus/issues/86

Access to the native Message is now possible as of version 1.4.0 of the transport.
See the announcement here: NServiceBus.Transport.AzureServiceBus 1.4.0 - Minor release available