New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ServiceBusTrigger should manage message lock renewals automatically #591
Comments
From the online documentation below, it seems that lock renewal is taken care of. Am I understanding it correctly? https://azure.microsoft.com/en-us/documentation/articles/websites-dotnet-webjobs-sdk-service-bus/ How ServicebusTrigger works The SDK receives a message in PeekLock mode and calls Complete on the message if the function finishes successfully, or calls Abandon if the function fails. If the function runs longer than the PeekLock timeout, the lock is automatically renewed. |
Hmmm, yes, that article does suggest that. Can you try a simple example function where you just Task.Delay(TimeSpan.FromMinutes(15)) or something and verify that the message becomes available again? If so, we know the lock isn't being held. We need to prove that first. @tdykstra Regarding your ServiceBusTrigger sample - is that a working sample that you still have? Are you sure message locks are renewed in the RTM bits? I don't see any calls to RenewLock in the codebase. For reference, the code that receives a SB message and invokes the job function with it is here. No renew lock timer is set up on the message, as is the case with Azure Queue messages (that code here). |
Thanks for looking into this. Will try with a dummy task. Meanwhile, about writing custom MessageProcessor, I see that this feature isn't available in 1.0.1, but 1.1.0 hasn't been released yet. Is there a timeline for releasing 1.1.0? |
The beta1 for the v1.1.0 release is on nuget.org now. You can also get the latest and greatest prerelease packages from our "nightlies" feed, instructions here. We'll be reasing the rc1 build for v1.1.0 very soon on nuget.org - we're finishing the release up now. If it turns out that lock renewals for ServiceBus aren't possible, we can address that soon in a follow up bug fix release. However, the MessageProcessor might be a workaround for you until then. |
@MatthewC I recall a question about lock renewal coming up in an SO post, and I put in the doc what I undeerstood from Pranav's answer: http://stackoverflow.com/questions/26570988/azure-webjob-sdk-service-bus-documentation |
On further investigation, while the ServiceBus documentation is very poor, it does appear that OnMessageAsync does do automatic renewals. These are goverened by the OnMessageOptions.AutoRenewTimeout value, which can be increased as needed. For a JobHost, you can override the default OnMessageOptions by setting it via ServiceBusConfiguration.OnMessageOptions, which you can then pass into config.UseServiceBus() on host startup. |
Confirmed that the lock is renewed using dummy Task.Delay(15min) example. Haven't tested longer delays, but 15mins is quite alright for my use cases for now. |
Thanks for confirming. Sorry about the confusion - I wasn't aware renewals were handled by SB by default. For Queues we had to do that ourselves. |
QueueTrigger ensures that message visibility is updated periodically while a message is being processed. For ServiceBus messages, the analog is to renew the message lock (BrokeredMessage.RenewLock). We don't do this currently, meaning if a function runs longer than the default lock (I think 5 minutes), the lock will be lost.
For example, here's a link how QueueListener manages message visibility by creating a visibility timer. ServiceBus listener should do the same thing.
Here's the SO reported issue: http://stackoverflow.com/questions/33391888/service-bus-message-abandoned-despite-webjobs-sdk-handler-completed-successfully/33403158#33403158
The text was updated successfully, but these errors were encountered: