4.1.0
Added ServiceBusQueueOptions.LockRenewalDelay
option that controls the delay between lock renewal commands are sent to ServiceBus, when background job is still processed by a worker. Previously lock renewal attempt was made just a second before the deadline, and we had the following problems.
- Delay was calculated as a difference between message's timestamp that was based on ServiceBus host time, and processing server's current time. So when time on those machines was non-synchronised (very likely scenario), we may send lock renewal query too late.
- We have only a single attempt to renew a lock. When that attempt fails even due to a transient error like network blip (we are in cloud, they happen constantly), lock renewal process is stopped, causing unwanted retry.
Instead, the new option allows us to send renewal queries with the configured delay. We can set it to 15 seconds, with lock timeout of 1 minute and have ~4 attempts to renew the lock even if there are transient errors.
This release doesn't change the previous behaviour that will be used by default. The new behaviour is optional, and may be changed to the default one in future versions.