I'd like to understand how much of the following scenario is supported by the Azure Service Bus:
Worker server notifies an unknown number of webservers of an event
Each web server processes the message (processing takes sometime - 10-30 minutes)
When every web server is done with processing of the first message, all of the web servers need to receive a new event. Basically I'm trying to synchronize a number of web roles after performing a long-running job on each web role.
How much of this can I get "for free" from Azure service bus?
Azure Service Bus has a lot of rich messaging features to help with both the Pub/Sub aspect of your requirement as well as the request/response correlation. The concept of sessions (grouped/related) messages along with session state can be very helpful here. Following are some specific links that may help:
MSDN article on sessions: http://msdn.microsoft.com/en-us/magazine/jj863132.aspx
Sample for using sessions: http://code.msdn.microsoft.com/windowsazure/Brokered-Messaging-Session-41c43fb4
Request/Response sample: http://code.msdn.microsoft.com/windowsazure/Brokered-Messaging-Request-0ce8fcaf
Talk on correlation etc.: http://channel9.msdn.com/Blogs/Subscribe/Service-Bus-Messaging-Deep-Dive
You may also want to take a look at the recently released Service Bus Durable Task Framework preview here. For some samples of how to use this framework, see here.
Basically, using this framework on top of Service Bus features such as sessions etc you could write some C# orchestration code that does something roughly like this:
...
// phase 1
List<Task> taskList = new List<Task>();
foreach (var serverName in serverList)
{
taskList.Add(context.ScheduleTask<object>(typeof(ExecutePhase1OnWebServerActivity), serverName));
}
// wait for all of the executions to finish
await Task.WhenAll(taskList);
// phase 2
taskList = new List<Task>();
foreach (var serverName in serverList)
{
taskList.Add(context.ScheduleTask<object>(typeof(ExecutePhase2OnWebServerActivity), serverName));
}
await Task.WhenAll(taskList);
...
Based on how i interpret your question, it Sounds to me like the complicated bit would be not sending the 2nd message until you are sure all of the unknown number of servers had processed their message.
While service bus would offer pub/sub and correlation features which could help you here, to me your describing a pattern where servers would register their interest and also acknowledge that they have processed their message so something would then count up the ack's and once everyone had ack'd the 2nd message would be sent.
This orchestration isnt something service bus can help you with. This puts you in the place of building something in a worker role or possibly using BizTalk when its available in a VM role.
Something like a long running BizTalk orchestration to handle the registration, tracking of acknowledgements and publishing a new message combined with a service bus topic for pub sub to the web servers could be a way to do this
This looks to me like a combination of Workflow Foundation and Service Bus.
Related
Team,
I would like to monitor a azure service bus dead letter queue length using normal C#. it should throw an exception when the receiver is not able/late to process messages from the active queue and due to time delay the count in the dead letter queue increases.
Is there a way without using ApplicationInsights ?
While using the full framework .NET client still provides message counts, according to the Azure Service Bus team the advised way is to use Azure Monitor service. The service has a .NET client that can be used to obtain the needed information (example). Service Bus team has also published a sample here. The client has not provided all the information in the past, but that is work in progress and could be different now than before.
In case you're still planning to use Service Bus client to retrieve message counts, I highly advise to use .NET Standard client rather than full framework client. The "new" client doesn't have NamespaceManager, but it has an equivalent, ManagementClient that will provide the functionality you're looking for, including improvements over its predecessor and bug fixes moving forward. The "old" client is on a limited support only.
If you are using the "old" Service Bus SDK, you can get it from MessageCountDetails:
var msg = NamespaceManager.CreateFromConnectionString(connectionString);
var queue = msg.GetQueue(queueName);
var dlqCount = queue.MessageCountDetails.DeadLetterMessageCount;
It is possible to fetch the Count of Messages(both active and dead-letter) in a Queue with the help of the latest Azure Monitor Metrics. Or you can make use of the Azure Monitor in Azure portal, which allows you to configure dashboards and alerts.
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 is.
Essentially I just want to take a message from the queue, perform an API lookup on some internally held data (perhaps using hybrid services?) and then perhaps post a message back to a different queue with some additional information .
I looked at worker roles(?) -- is that something that could do it?
I should mention that I've been looking at doing this with node.js.
Check out these videos from Scott Hanselman and Mark Simms on Azure Queues.
It's C# but you get the idea.
https://channel9.msdn.com/Search?term=azure%20queues%20simms#ch9Search
Touches on:
Storage Queues vs. Service Bus Queues
Grabbing messages in bulk vs. one by one (chunky vs. chatty)
Dealing with poison messages (bad actors)
Misc implementation details
Much more stuff i can't remember now
As for your compute, you can either do a VM, a Worker Role (Cloud Services), App Service Webjobs, or Azure Functions.
The Webjobs SDK and Azure Functions bot have a way to subscribe to Queue events (notify on message).
(Listed from IaaS to PaaS to FaaS - Azure Functions - if such a thing exists).
Azure Functions already has sample code provided as templates to do all that with Node. Just make a new Function and follow the wizard.
If you need to touch data on-prem you either need to look at integrating with a VNET that has site-to-site connectivity back to your prem, or Hybrid Connections (App Service only!). Azure Functions can't do that yet, but every other compute is a go.
https://azure.microsoft.com/en-us/documentation/articles/web-sites-hybrid-connection-get-started/
(That tutorial is Windows only but you can pull data from any OS. The Hybrid Connection Manager has to live on a Windows box, but then it acts as a reverse proxy to any host on your network).
To deal with Azure ServiceBus Queue easily, the best option seems to be Azure Webjob.
There is a ServiceBusTrigger that allows you to get messages from an Azure ServiceBus queue.
For node.js integration, you should have a look at Azure Function. It is built on top of the webjob SDK and have node.js integration :
Azure Functions NodeJS developer reference
Azure Functions Service Bus triggers and bindings for queues and topics
In the second article, there is an example on how get messages from a queue using Azure Function and nodejs :
module.exports = function(context, myQueueItem) {
context.log('Node.js ServiceBus queue trigger function processed message', myQueueItem);
context.done();
};
I have looked around the Azure portal and searched the net, but I have been unable to find an answer. Is there a way, perhaps via the api or powershell, to get metrics on webjobs? Such as average runtime per individual job? I would also like to find out the average queued time of a message that a webjob triggers from (though that is probably a storage metric not a webjob metric). Any pointers would be appreciated.
As Igorek said, I don't think it is possible either. There are many tools to monitor application. Two of them have Azure integration:
Application Insights
New relic
I have used Application Insights to send metric from a webjob. You can follow this tutorial to setup Application insights n your webjob:
Application Insights on Windows Desktop apps, services and worker roles
If you want to calculate the time to process a message from a queue, you can do something like that:
public async Task ProcessAsync([ServiceBusTrigger("queueName")] BrokeredMessage incommingMessage)
{
var stopwatch = Stopwatch.StartNew();
// Process your message
...
stopwatch.Stop();
// You should only instantiate the TelemetryClient once in your application.
var telemetryClient = new TelemetryClient() { InstrumentationKey = "MyInstrumentationKey"};
//Send your metric
telemetryClient.TrackMetric("ProcessQueueMessageElapsedTime", stopwatch.ElapsedMilliseconds);
}
Don't think this is possible without 3rd party services.. in fact, the only one I know that does this stuff specifically is CloudMonix, which I'm affiliated with.
I want to create an Azure application which does the following:
User is presented with a MVC 4 website (web role) which shows a list of commands.
When the user selects a command, it is broadcast to all worker roles.
Worker roles process the task, store the results and notify web role
Web role displays the combined results of the worker roles
From what I've been reading there seem to be two ways of doing this: the Windows Azure Service Bus or using Queues. Each worker role also stores the results in the database.
The Service Bus seems more appropriate with its publish/subscribe model, so all worker roles would get the same command and roughly the same time. Queues seem easier to use though.
Can the service bus be used locally with the emulator when developing? I am using a free trial and cannot keep the application constantly whilst still developing. Also, when using queues how can you notify the web role that processing is complete?
I agree. ServiceBus is a better choice for this messaging requirement. You could, with some effort, do the same with queues. But, you'll be writing a lot of code to implement things that the ServiceBus already gives you.
There is not a local emulator for ServiceBus like there is for the Azure Strorage service (queues/tables/blobs). However, you could still use the ServiceBus for messaging between roles while they are running locally in your development environment.
As for your last question about notifying the web role that processing is complete, there are a several ways to go here. Just a few thoughts (not exhaustive list)...
Table storage where the web role can periodically check the status of the unit of work.
Another ServiceBus Queue/topic for completed work.
Internal endpoints. You'll have to have logic to know if it's just an update from worker role N or if it is indicating a completed unit of work for all worker roles.
I agree with Rick's answer, but would also add the following things to think about:
If you choose the Service Bus Topic approach then as each worker role comes online it would need to generate a subscription to the topic. You'll need to think about subscription maintenance of when one of the workers has a failure and is recycled, or any number of reasons why a subscription may be out there.
Telling the web role that all the workers are complete is interesting. The options Rick provides are good ones, but you'll need to think about some things here. It means that the web role needs to know just how many workers are out there or some other mechanism to decide when all have reported done. You could have the situation of five worker roles receieving a message and start working, then one of them starts to repeatedly fail processing. The other four report their completion but now the web role is waiting on the fifth. How long do you wait for a reply? Can you continue? What if you just told the system to scale down and while the web role thinks there are 5 there is now only 4. These are things you'll need to to think about and they all depend on your requirements.
Based on your question, you could use either queue service and get good results. But each of them are going to have different challenges to overcome as well as advantages.
Some advantages of service bus queues is that it provides blocking receipt with a persistent connection (up to 100 connections), it can monitor messages for completion, and it can send larger messages (256KB).
Some advantages of storage queues over the service bus solution is that it's slightly faster (if 15 ms matters to you), you can use a single storage system (since you'll probably be using Storage for blob and table services anyways), and simple auto-scaling. If you need to auto-scale your worker roles based on the load, passing the the requests through a storage queue makes auto-scaling trivial -- you just setup auto-scaling in the Azure Cloud Service UI under the scale tab.
A more in-depth comparison of the two azure queue services can be found here: http://msdn.microsoft.com/en-us/library/hh767287.aspx
Also, when using queues how can you notify the web role that processing is complete?
For the Azure Storage Queues solution, I've written a library that can help: https://github.com/brentrossen/AzureDistributedService.
It provides a proxy layer that facilitates RPC style communication from web roles to worker roles and back through Storage Queues.
I have been struggling with this concept for a while. I am attempting to come up with a loosely coupled Azure component design that is completely scalable using Queues and worker roles, which dequeue and process the items. I can scale the worker roles at will, and publishing to the queue is never an issue. So far so good, but, it seems that the only real world model this could work in is fire and forget. It would work fantastic for logging and other one way operations, but let's say I want to up load a file using queues/worker roles, save it to blob, then get a response back once it is complete. Or should this type of model not be used for online apps? What is the best way to send a notification back once an operation is completed? Do I create a response Q, then (somehow) retrieve the associated response? Any help is greatly appreciated!!!!!
I usually do a polling model.
Client (usually a browser) sends a request to do some work.
Front-end (web role) enqueues the work and replies with an ID.
Back-end (worker role) processes the queue and stores the result in a blob or table entity named .
Client polls ("Is done yet?") at some interval.
Front-end checks to see if the blob or table entity is there and replies accordingly.
See http://blog.smarx.com/posts/web-page-image-capture-in-windows-azure for one example of this pattern.
you could also look into the servicebus appfabric instead of using queues. with the servicebus you can send messages, use queues etc all from the servicebus appfabric. you could go to publish and subscribe instead of polling then!