azureservicebus

I'm simply trying to work out how best to retrieve messages as quickly as possible from an Azure Service Bus Queue. I was shocked that there wasn't some way to properly subscribe to the queue for notifications and that I'm going to have to poll. (unless I'm wrong in which case the documentation is terrible). I got long polling working, but checking a single message every 60 seconds looks like it'll cost around £900 per month (again, unless I've misunderstood that). And if I add a redundant/second service to poll it'll double. So I'm wondering what the best/most cost efficient way of doing it

I am developing a solution which involves reading messages from an Azure service bus queue using the BizTalk SB-Messaging adapter. I am using the BizTalk Deployment Framework to deploy the application without user input. Some adapters have an option to acquire credentials for external systems using the Single Sign-On database (option 'Use SSO'). The SB-Messaging adapter doesn't have this feature, and requires that either ACS (Access Control Service) or SAS (Shared Access Secret) credentials for the service (in this case a queue) are entered in the UI. BTDF can also set them by entering them in

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

I am using Azure ServiceBus Queues through the .net SDK. There is a flag on the OnMessageHandler/OnMessageOptions called "AutoRenewTimeout", but there seems to be confusion on what this value actually means. On the official documentation here https://msdn.microsoft.com/en-us/library/microsoft.servicebus.messaging.onmessageoptions.aspx it suggests that the AutoRenewTimeout should be greater than the queue lockduration. Gets or sets the maximum duration within which the lock will be renewed automatically. This value should be greater than the longest message lock duration; for example, the

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

We are experiencing lots of these exceptions sending events to EventHubs during peak traffic: "Failed to send event to EventHub. Exception : Microsoft.ServiceBus.Messaging.MessagingException: The server was unable to process the request; please retry the operation. If the problem persists, please contact your Service Bus administrator and provide the tracking id." or "Failed to send event to EventHub. Exception : System.TimeoutException: The operation did not complete within the allocated time " You can see it clearly here: As you can see, we got lots of Internal Errors, Server Busy Errors,