I was using AzureQueue to communicate between roles. My messages like "GoToMaintenanceMode", "StopSendingEmails", "DoNotAcceptRequests" etc. But I realized that, it won't work for my scenario when I have multiple instances due to queue message will shows up only 1 instance at a time.
So my question is beside the options below is there an elegant way to handle this issue something like Role.AllInstances.Run() etc.?
the method I'm using it right now:
instance peeks the message, adds it's own instance id to the message and puts it back to the queue, and does not peek the message if it contains it's own instance id.
P.S. I do not want to implement TCP listener, asking for native solution if there is one.
You could use Windows Azure Service Bus Topics/Subscriptions instead of queues. They support multicasting (i.e. multiple receivers).
A short how-to guide can be found here
http://www.windowsazure.com/en-us/develop/net/how-to-guides/service-bus-topics/
Basically, your queue would become a Topic all your instances would become Subscriber to the Topic.
As you do not want TCP listener option or Service bus option. How about extending your same idea with multiple queues. Instance1 will read from Queue1 and Instance2 will read from Queue2 and so on. The only thing you need to handle is the number of queues and simultaneous adding of queue messages to all the queues.
Related
In my messaging app I decided to allocate an individual queue for a client. This way routing and security are quite easy. But I can't figure out how to deal with dead-letter queues then (when message expires, let's say). I want to use serverless approach with Azure functions to handle messages from DLQ. It's easy to setup to trigger a function when a message gets placed in a queue. But if I have 1000 clients, that would require 1000 functions?.. From what I can see you can attach a function to a single "trigger" - meaning single queue. Am I missing something here? what's the right approach to uniformly deal with DLQ messages?
Any help is appreciated. Thank you.
If your concern is how to deal with thousands of DLQs, one possible solution would be to configure your queues and set ForwardDeadLetteredMessagesTo property in each of the queue to point to another queue.
That way the dead-lettered messages from all the queues will go in a single queue and you can attach a Function to that queue for processing of such messages.
We have a Azure service fabric micro-service which listen to multiple azure service bus topics(Topic A, Topic B).
Topic A has more then 10 times message traffic then topic B. and to handle the scale-ability of service we will create the multiple instance of service.
My first question is, In most of the services instance will not get the message in Topic B, As Topic B has less traffic, So will it be waste of resources ?
2 Is it better to create different micro-services for Topic A and Topic B listeners, and create 10x instance of micro-service which listen to topic A and x instance of topic B listener service ?
Is create a message listener in azure service bus, keep on pulling message every time ? means continuously looking/ checking for message, message is there or not.
Thanks Guys for your supports.
If one service receives messages from 2 topics, there's little waste of resources. Listening for messages is not a very resource intensive process.
This depends on your application requirements.
This depends on whether you are using SBMP / SOAP (default) or AMQP as the communication protocol. AMQP is connection based. SBMP does (long) polling.
Microservices advocates the idea of loosely coupled services, where each micro-service will handle his own domain.
Following the microservices approach, if you understand that you had to create two different topics to publish your messages, probably it is because they have different scopes\domain, needing their own micro-service.
In your description it is hard to identify if the domain of TopicA and TopicB are related, so we can not offer a good suggestion.
In any case, if one service listen for both topics, let's assume TopicA handles 1000 messages and TopicB handles 100 per second.
In case you have to publish a new version of your application to handle changes on TopicB messages, you would have to stop the handling of TopicA, that was not necessary. So you are coupling the services, that to begin with should be two independent services, or both topics should be handle as a single one.
Regarding your questions:
1 My first question is, In most of the services instance will not get
the message in Topic B, As Topic B has less traffic, So will it be
waste of resources ?
Waste of resources is relative how you design your application, it might be if your service listen the queue\topic and handle it at the same time, and uses too much memory to keep running all the time. In this scenario, would be case to split them and make a Queue\Topic Listener and other Message Handler that will receive the message to process, and if it keep too long without processing messages you shut it down, leaving just the listener. You could also use actors instead of a service.
2 Is it better to create different micro-services for Topic A and
Topic B listeners, and create 10x instance of micro-service which
listen to topic A and x instance of topic B listener service ?
Yes for the services, regarding the the number of instances, it should be driven by the size of the queue, otherwise you would have too much listeners and also wasting resources, if you follow the approach of splitting the services, you would need one listener receiving the messages from the queue\topic and it would delivery the messages to multiple messages handlers(service instances\actors) and the queue\topic listener control the number of running instances at same time.
3 Is create a message listener in azure service bus, keep on pulling
message every time ? means continuously looking/ checking for message,
message is there or not.
Is not the only approach, but it's correct.
If there are no longer any publishers or subscribers reading nor writing to a Queue, Topic, or Subscription, because of crashes or other abnormal terminations (instance restart, etc.), is that Queue/Topic/Subscription effectively orphaned?
I tested this by creating a few Queues, and then terminating the applications. Those Queues were still on the Service Bus a long time later. It seems that they will just stay there forever. That would be wonderful if we WANTED that behavior, but in this case, we do not.
How can we detect and delete these Queues, Topics, and Subscriptions? They will count towards Azure limits, etc, and we cannot have these orphaned processes every time an instance is restarted/patched/crashes.
If it helps make the question clearer, this is a unique situation in which the Queues/Topics/Subscriptions have special names, or special Filters, and a very limited set of publishers (1) and subscribers (1) for a limited time. This is not a case where we want survivability. These are instance-specific response channels. Whether we use Queues or Subscriptions is immaterial. If the instance is gone, so is the need for that Queue (or Subscription).
This is part of a solution where each web role has a dedicated response channel that it monitors. At any time, this web role may have dozens of requests pending via other messaging channels (Queues/Topics), and it is waiting for the answers on multiple threads. We need the response to come back to the thread that placed the message, so that the web role can respond to the caller. It is no good in this situation to simply have a Subscription based on the machine, because it will be receiving messages for other threads. We need each publishing thread to establish a dedicated response channel, so that the only thing on that channel is the response for that thread.
Even if we use Subscriptions (with some kind of instance-related filter) to do a long-polling receive operation on the Subscription, if the web role instance dies, that Subscription will be orphaned, correct?
This question can be boiled down like so:
If there are no more publishers or subscribers to a Queue/Topic/Subscription, then that service is effectively orphaned. How can those orphans be detected and cleaned up?
In this scenario you are looking for the Queue/Subscriptions to be "dynamic" in nature. They would be created and removed based on use as opposed to the current explicit provisioning model for these entities. Service Bus provides you with the APIs to perform create/delete operations so you can plug these on role OnStart/OnStop events appropriately. If those operations fail for some reason then the orphaned entities will exist. Again you can run clean up operation on them based on some unique identifier for the name of the entities. An example of this can be seen here: http://windowsazurecat.com/2011/08/how-to-simplify-scale-inter-role-communication-using-windows-azure-service-bus/
In the near future we will add more metadata and query capabilities to Queues/Topics/Subscriptions so you can see when they were last accessed and make cleanup decisions.
Service Bus Queues are built using the “brokered messaging” infrastructure designed to integrate applications or application components that may span multiple communication protocols, data contracts, trust domains, and/or network environments. The allows for a mechanism to communicate reliably with durable messaging.
If a client (publisher) sends a message to a service bus queue and then crashes the message will be stored on the Queue until as consumer reads the message off the queue. Also if your consumer dies and restarts it will just poll the queue and pick up any work that is waiting for it (You can scale out and have multiple consumers reading from queue to increase throughput), Service Bus Queues allow you to decouple your applications via durable cloud gateway analogous to MSMQ on-premises (or other queuing technology).
What I'm really trying to say is that you won't get an orphaned queue, you might get poisoned messages that you will need to handled, this blog post gives some very detailed information re: Service Bus Queues and their Capacity and Quotas which might give you a better understanding http://msdn.microsoft.com/en-us/library/windowsazure/hh767287.aspx
Re: Queue Management, you can do this via Visual Studio (1.7 SDK & Tools) or there is an excellent tool called Service Bus Explorer that will make your life easier for queue managagment: http://code.msdn.microsoft.com/windowsazure/Service-Bus-Explorer-f2abca5a
*Note the default maximum number of queues is 10,000 (per service namespace, this can be increased via a support call)
As Abhishek Lai mentioned there is no orphan detecting capability supported.
Orphan detection can be implement externally in multiple ways.
For example, whenever you send/receive a message, update a timestamp in an SQL database to indicate that the queue/tropic/subscription is still active. This timestamp can then be used to determine orphans.
If your process will crash which is very much possible there will be issue with the message delivery within the queue however queue will still be available to process your request. Handling Application Crashes and Unreadable Messages with Windows Azure Service Bus queues are described here:
The Service Bus provides functionality to help you gracefully recover from errors in your application or difficulties processing a message. If a receiver application is unable to process the message for some reason, then it can call the Abandon method on the received message (instead of the Complete method). This will cause the Service Bus to unlock the message within the queue and make it available to be received again, either by the same consuming application or by another consuming application.
In the event that the application crashes after processing the message but before the Complete request is issued, then the message will be redelivered to the application when it restarts. This is often called At Least Once Processing, that is, each message will be processed at least once but in certain situations the same message may be redelivered. If the scenario cannot tolerate duplicate processing, then application developers should add additional logic to their application to handle duplicate message delivery. This is often achieved using the MessageId property of the message, which will remain constant across delivery attempts.
If there are no longer any processes reading nor writing to a queue, because of crashes or other abnormal terminations (instance restart, etc.), is that queue effectively orphaned?
No the queue is in place to allow communication to occur via Brokered Messages, if all your apps die for some reason then the queue still exists and will be there when they become alive again, it's the communication channel for loosely decoupled applications. Regards Billing 'Messages are charged based on the number of messages sent to, or delivered by, the Service Bus during the billing month' you won't be charged if a queue exists but nobody is using it.
I tested this by creating a few queues, and then terminating the
applications. Those queues were still on the machine a long time
later.
The whole point of the queue is to guarantee message delivery of loosely decoupled applications. Think of the queue as an entity or application in its own right with high availability (SLA) as its hosted in Azure, your producer/consumers can die/restart and the queue will be active in Azure. *Note I got a bit confused with your wording re: "still on the machine a long time later", the queue doesn't actually live on your machine, it sits up in Azure in a designated service bus namespace. You can view and managed the queues via the tools I pointed out in the previous answer.
How can we detect and delete these queues, as they will count towards
Azure limits, etc.
As stated above the default maximum number of queues is 10,000 (per service namespace, this can be increased via a support call), queue management can be done via the tools stated in the other answer. You should only be looking to delete queue's when you no longer have producer/consumers looking to write to them (i.e. never again). You can of course create and delete queues in your producer/consumer applications via the namespaceManager.QueueExists, more information here How to Use Service Bus Queues
If it helps make the question clearer, this is a unique situation in which the queues have special names, and a very limited set of publishers (1) and subscribers (1) for a limited time.
It sounds like you need to use Topics & Subscriptions How to Use Service Bus Topics/Subscriptions, this link also has a section on 'How to Delete Topics and Subscriptions' If you have a very limited lifetime then you could handle topic creation/deletion in your app's otherwise you could have have a separate Queue/Topic/Subscription setup/deletion script to handle this logic...
I'm just getting started with Windows Azure Service Bus (Topics & Queues) and I'm trying to implement a Competing-Consumers messaging pattern.
Essentially, I want to have a set of message Producers and a set of message Consumers. Once a message is produced, I want the first available Consumer to process the message. No other Consumers should get the message.
Is there a way to do this in Azure?
Simple. Just make two (or more) receivers that concurrently receive from a single queue and you're done. Any retrieved message goes to exactly one of those receivers since the cursor over the mesasage log is advanced as a message is taken. Competing consumers are an inherent capability of a networked queue so there's really nothing special needed.
If you need the opposite - each message goes to each consumer - you make a subscrioption per consumer which gives you an isolated cusor over the message log that can move independent of other receivers. For kicks, you can obviously also have competing consumers on a subscription.
Clemens
Topics are a feature of brokered messaging, but are a one-to-many "publish/subscribe" pattern. Queues are one-to-one message communication. So yes, it sounds like you should simply use queues. Also see http://msdn.microsoft.com/en-us/library/hh689723(VS.103).aspx.
You probably don't want Topics then, but rather Brokered Messaging.
You can emulate Topic-like functionality in Brokered Messaging by using the message's Label and/or Content Type properties along with the PeekLock receive mode.
We are thinking of speparate Queues for:
Request (RequestQueue)
Response (ResponseQueue)
Scenario:
Worker role will putMessage to RequestQueue e.g. GetOrders
Third party will monitor RequestQueue. If they see GetOrders
request they will getMessage, process them and put the response in
ResponseQueue.
Question:
If I putMessage to RequestQueue, I will like to get results back from ResponseQueue. Is there easy way to achieve this and how?
Thank you.
No, this is not possible. If you put a message in a queue, you must pop the message from the same queue (it will not magically appear in any other queue). Perhaps if you explained more why you think you need two separate queues here for push/pop, there might be a more expansive answer and suggestion.
EDIT: Perhaps I misunderstood your intent. I guess I don't get the question now - can you help clarify. You seem to be asking how to put a message on one queue, acknowledge it by putting another message on another queue, and have someone read the acknowledgment from the second queue? What is the question here? I should point out that you won't want some 3rd party to read directly from a Windows Azure queue as that would require sharing the master storage key with them (a non-starter). Perhaps you are looking for how to have 3rd parties read from a queue?
EDIT 2: Sounds like you want to consume messages with a 3rd Party. Windows Azure queues probably are not a good fit as I mentioned due to security reasons (you need to share the master key). Instead, you could either layer a WCF service over the queue (using queues via proxy) or use the queueing from the Service Bus - that will allow you to have separate credentials. Using the Service Bus capability might be the right choice here in terms of simplicity. Take a look here for demos.
Have a worker of some sort monitor the question queue, then post an answer to the answer queue. Interface out the queue managers and you shouldn't have any problems using any sort of queue tech. Also, the worker doesn't really need to use a queue for answers..
Caveats:
Worker service has access to both queues
Each queue item contains a serialized foreign key to identify themselves.