MicrosoftHi David. I am not familiar with the JMS service bus connection, but I do know my way around Azure Service Bus reasonably well and I wanted to share a few thoughts with you that might be helpful....
When a client of any sort receives messages off of an Azure Queue, you can specify a "Receive Mode" of either Peek-Lock (which is the default) or Receive-and-Delete. With Peek-Lock, as you have experienced, the receive operation takes out a transient lock on the message and bad things can happen when this lock expires. You can control the timeout of this lock with a setting on the Queue:
This can be set for hours or even days. So, one option you might have to simply extend this timeout thereby giving your app more time to process the batch of messages.
Another thing to be aware of is that when a message lock times out it doesn't go to the Dead Letter Queue immediately. Instead, it goes back into the Active Queue where it is retried a set number of times. After it fails that many times, then it does to Dead Letter. This, too, is configurable:
My worry with this is that not only are your messages timing out, but your app may be churning away trying them multiple times before they end up in the Dead Letter queue. Setting Max Delivery Count to 1 would at least prevent churn. I guess it depends on if you have legitimate reasons to retry the messgaes.
If you really don't need to retry messages, you might then, consider using Receive-and-Delete. With this option, messages are deleted from the queue immediately. There is no lock at all and no need to Complete the message. It is simple and clean. The challenge for you may be that this receiver option is set in the client code, not through configuration, so you'd have to dig around and see if this JMS service bus consumer thing supports it. Here is a snippet of C# code to show what it would look like if you were writing your own queue reader:
I hope that helps! Please let me know if you have follow-up questions. -Matthew
