azure-servicebus-queues

I asked the very same question few days ago: Unable to "Peek" messages from an Azure Service Bus Queue using AMQP and Node . I'm asking the same question again but with a few differences (hence, please don't mark this question as a duplicate of the other question): In the previous question, I was using nodeamqp10 library however based on some comments on the Github page for this library, I ended up using rhea instead of nodeamqp10 library. With some help from Azure Service Bus team, I made some progress and now I am getting an error back from Azure Service Bus which tells me that I am on the

I recently created some partitioned queues from where I send and receive all the time. They've run as non-partitioned in the past without any of my current issues. The problem is, I have a constant number of messages in the queue that I can not receive. I always get nothing back when not sending any other messages to the queues but when I send messages to the queues I receive the new messages without a problem. The messages that are stuck in the queue are active messages, not dead lettered. I'm suspecting they're stuck in a specific partition(s) but I don't know how to receive them. Since I

We are using a service bus queue in our project. We are in need of a functionality to remove all the messages from the queue when the administrator chooses to clear the queue. I searched on the net but could not find any function which does this inside the QueueClient class. Do I have to pop all the messages one by one and then marking them complete to clear the queue or is there a better way? QueueClient queueClient = _messagingFactory.CreateQueueClient( queueName, ReceiveMode.PeekLock); BrokeredMessage brokeredMessage = queueClient.Receive(); while (brokeredMessage != null ) {

I'm trying to read a message from an Azure ServiceBus queue using an Azure WebJob but it's throwing and exception: Unhandled Exception: System.InvalidOperationException: Found 2 DNS claims in authorization context. I've set the correct connection strings named "AzureWebJobsServiceBus", "AzureWebJobsDashboard" and "AzureWebJobsStorage" The WebJob Program code has been updated to use JobHostConfiguration: class Program { static void Main() { var config = new JobHostConfiguration(); config.UseServiceBus(); var host = new JobHost(config); host.RunAndBlock(); } } And the actual Job method public

Just a quick question regarding an Azure application. If I have a number of Web and Worker roles that need to communicate, documentation says to use the Azure Queue Service. However, I've just read that the new .NET Service Bus now also offers queues. These look to be more powerful as they appear to offer a much more detailed API. Whilst the .NSB looks more interesting it has a couple of issues that make me wary of using it in distributed application. (for example, Queue Expiration... if I cannot guarantee that a queue will be renewed on time I may lose it all!). Has anyone had any experience

I'm trying to figure out what is the best practice for using Service Bus from a Web-API. I've read that re-creating objects like QueueClient, SubscriptionClient and etc' is the wrong approach, so I need to reusing factories and clients. Service Bus client objects, such as Microsoft.ServiceBus.Messaging.QueueClient or Microsoft.ServiceBus.Messaging.MessageSender, are created through a MessagingFactory object, which also provides internal management of connections. You should not close messaging factories or queue, topic, and subscription clients after you send a message, and then re-create them

So the scenario is that I'm using an SB queue to throttle outgoing callbacks to other services. One of the standard problems with calling back to other services is that they may be down for uncontrollable amounts of time. Assuming I detect that the target is down/not responding, what is the best pattern for abandoning that message so that it doesn't reappear on the queue immediately? Here's are some approaches I'm either aware of, have tried or am considering: Obviously if I just use BrokeredMessage::Abandon() the message will be unlocked and put back on the queue. This is obviously