Particular
Message lock renewal not supported
The message lock renewal functionalty from the legacy ASB transport has not been implemented in the ASBS transport. The upgrade guide does not mention anything about this. Having some information and guidance about the removed API would be a helpful start (or potentially support for the removed functionality in the ASBS transport).
Is it possible to add this feature back in v7? We do acknowledge the potential problem it may bring, but our code base is so huge that we cannot afford any workaround at the moment. At the same time we need to host sender side in Linux container (run it on .net core). Could you please let me know if we can somehow officially request it? (i.e. change request)
Client: Thomson Reuters Manager: @[email protected]
P.S. We can also consider having sender side on v7 but handling side staying on v6 (not sure if it is possible though)
Is it possible to add this feature back in v7. We do acknowledge the potential problem it may bring, but our code base is so huge that we cannot afford any workaround at the moment.
The feature was deprecated due to multiple customers facing this specific issue of designing their system with an assumption that messages can be locked up to a certain time, and occasionally that would not work, breaking their design assumption and causing problems. Message lock extension is a client-side feature and is not guaranteed to be successful. This request could potentially have some argument if Microsoft kept things as they were for many years. But they don't. The messaging team is working on removing the message lock restriction. The new implementation will be a guaranteed operation w/o the need to extend the lock at all. Considering these two factors, it's tough to justify adding this feature to the transport.
At the same time we need to host sender side in Linux container (run it on .net core).
Send-only endpoints do not require message locking at all. If the senders are running on Linux, you can use the new transport w/o any issues.
We can also consider having sender side on v7 but handling side staying on v6 (not sure if it is possible, though)
Yes, that's possible but would require an alignment between the two different transport types you'll be using. I will follow-up offline to understand your scenario better and provide some more insights.
The feature will not be added to the transport, but the documentation will be updated to show how to achieve lock renewal when required. I'll update the issue when the documentation is published.
A sample has been published to demonstrate how to achieve message lock renewal using a custom pipeline behaviour. The sample applies to the current ASB transport.
Reopening to be able to re-discuss our stance on this during an enhancement release
We have added support for message lock renewal to the transport. The improvements are contained in v3.0.0 of the transport which should come out soon(ish)