I’m in the process of porting my system from SQLServer transport to Azure ServiceBus, and I have some long running handlers that do quite a bit of compute. None of this is prod yet so free to change anything without any restriction.
With SQLServer the compute would be allowed to execute to completion without risk of some timeout triggering a retry. ASB on the other hand has a default peek lock of 1 minute and a max of 5 minutes. I realise this can be extended in code with a peek lock retry but it’s always felt like I should be doing this differently.
Mauro posted an article (thanks to you Mauro) on this problem of long running handlers some time back, the sample repo using WCF to communicate with a worker.
I intend to do something similar where a saga maintains some state for the long process, and the worker implemented via dotnet’s background task queues. I wouldn’t necessarily be querying the “job” status as such, just relying instead on two things; the saga timeout beyond what should be enough time to complete a job, and sending a message from the job to indicate success or failure to the saga.
To the latter part of that, do you see any issues with using IMessageSession from an IHostedService in order to send a message to the saga? And any obvious things I am missing with this approach?
Edit:
I’ve just seen the article Transactions? None for me, thanks which is basically what I’d like to do I think, and negates the need to use IMessageSession as regular handlers are used still - meaning I can shift my existing handler to another endpoint that does immediate acknowledgement of incoming message.
Having said that, this article was linked from another discussion topic Long running Handler operation that can't be batched that essentially describes the use case well. There was another blog post linked from that titled “Long-running Operations with Azure Service Bus Transport” but the link is broken. Any chance someone can point me to a working link as I’d like to understand how it was resolved there?