Message Lock Duration about azure-service-bus-java

[jtaubensee]

@sharadholani - This is a new feature, that would need to be implemented by the service. With that said, what is the use case here?

I ask because even with a "shorter" lock duration of 30 seconds, our MessageHandler will automatically renew the lock for you. And generally speaking it is a bad practice to set a lock for a long duration. This is because a crashed process early on would keep that message from being re-delivered. i.e. its locked until the long lock expires.

[sharadholani]

We are not using QueueClient APIs. We are creating MessageReceiver objects directly and calling receive() , whenever we need to fetch messages.

I need to specify the message visibility timeout period when we make to call to get messages from service bus.
If this timeout period is less than the time required to process it, I would increase the lock duration by a specified amount by making an explicit call.

This feature is there in SQS and Azure Storage queue.
Our clients who would be moving from SQS to Service Bus would need a similar feature. Hence we would be needing APIs to control the visibility timeout period for a message.

[jtaubensee]

@sharadholani - We generally recommend using the Queue/Topic/Subscription client API's as it can help solve some of these issues for you, and the Message Sender/Receiver is more for advanced scenarios that aren't met by the simplicity of the clients.

While the new feature that you have recommended is something that we can consider, its not currently on our road map, and therefore there is no time frame associated with it. If you'd like to officially request it, please do so in our 'parent' repo: https://github.com/azure/azure-service-bus

In the meantime, you probably have two choices:

1. Use the MessageHandler that is available in the Queue/Subscription clients, which will renew the lock for you as needed.
2. Continue using the MessageReceiver and manually renew the lock when the message.getExpiresAtUtc() is within 10 seconds of expiring. In order to do this, you will need to start a new thread.

[sharadholani]

QueueClient registers an IMessageHandler object which has onMessageAsync function. This function is invoked whenever there is a message in the queue.

In our case , we need to receive messages on Demand. The client can ask at any instant to get messages from queue. Only then are we supposed to query the queue for messages.

That is why we are using MessageReceiver objects directly instead of QueueClient .
Hence the issue with message locks.

Will the QueueClient have this on demand receive messages from the queue feature anytime soon ?

[jtaubensee]

@sharadholani - I'm going to close this issue for now, as this isn't something that we are able to focus on during preview. As we've discussed outside of this thread, I think the best thing to do would be to create an extension method that will handle renewing the lock for you on the receiver.