I am new to activemq and trying to use it as a messaging service in C#.net application.
I was able to create Publisher/Subscriber for durable topics. But for my application requirement I need to use Durable queue's. I don't see any create consumer method available for durable queue in Apache.NMS api. So, how can I create pub/sub using durable queues?
Queue's are durable by nature. You don't have to do anything special for a consumer when subscribing to a Queue, messages sent to the Queue that are marked as Persistent will survive a broker restart and remain on the Queue. Your Queue subscription will pull messages off in order and they will only be removed from the Queue when you Ack them.
Related
I've created an Azure Function App which is triggered from Azure Service Bus Queues. The Service Bus has two queues in it and there is a function with a trigger for each of the queues. The Function App is developed using C# in Visual Studio and uses package deployment publishing.
What I would like to do is be able to indicate that one function/trigger should be processed before the other if they both have messages waiting. (They both do basically the same thing but one queue is for handling messages with a higher priority since queues are only FIFO.)
I have read that functions are processed in alphabetical order but that doesn't feel like something to rely on really.
Is there any way to explicitly indicate a priority (or even a scale-out preference) for one function/trigger over another?
(They both do basically the same thing but one queue is for handling messages with a higher priority since queues are only FIFO.)
The above scenario looks like competing consumers which has a dedicated design pattern known as competing consumers pattern where it contains the limitation with the messaging order in this pattern.
Consumer service instances may receive messages in any order, and this order need not correspond to the order in which the messages were created.
So unfortunately, it's not possible to prioritize one function over another function listening to the Service Bus queue.
You can control the activity function & orchestrator but not the starter function using the Azure Durable Functions.
Microsoft Azure Service Bus Queues can implement guaranteed first-in-first-out ordering of messages by using message sessions. For more information, see Messaging Patterns Using Sessions.
I'm working with Azure Service bus queue, I have two listeners for the same queue, how can i make sure that one receiver1 should get the queue message all the time not the other one?
Note: 1. Implemented all the code in C#.
2. I'm aware about the Topics, above scenario is specific to queue.
We have created Azure service bus queue and have a azure function - servicebus queue trigger subscribed to it. We now want this queue to convert to Topic as we will need multiple subscription to it. is there a way that we can convert queue to Topic without deleting queue and re creating this as a Topic. I understand that Azure function code which is in c# needs to be changed so it points to service bus topic.
Thanks,
Punit Singhi
Use the ForwardTo feature for forwarding a message to the topic entity.
I am new to Azure Service Bus and would like to know if I can multiple subscribers to a queue or topic? In rabbit MQ I can have multiple subscribers to 1 publisher.
What I am trying to do is, I am using CQRS and when certain commands come into the system when the event is handled I want to push them into a message queue.
I want 2 subscribers to be able to get the messages from that queue, one for me to process internally. another one for process and send externally.
I am new to Azure Service Bus and would like to know if I can multiple
subscribers to a queue or topic?
Yes. This is possible with Azure Service Bus Topics. There can be multiple subscribers to a message sent to a topic. From this link:
In contrast to queues, in which each message is processed by a single
consumer, topics and subscriptions provide a one-to-many form of
communication, in a publish/subscribe pattern. Useful for scaling to
very large numbers of recipients, each published message is made
available to each subscription registered with the topic. Messages are
sent to a topic and delivered to one or more associated subscriptions,
depending on filter rules that can be set on a per-subscription basis.
The way it works is that you create a topic and then create multiple subscriptions in that topic. In each subscription, you can define message filtering rules. When a message is sent to a topic, Azure Service Bus matches that message against the filtering rules in each subscription and if a matching rule is found, then the message is sent to that subscription.
I wanted to add something to the discussion: from the following article it seems that each listener would have to create a different subscriber in azure before listening to the same topic. Basically a topic will have multiple subscribers (every subscription with a single listener) and so the service bus will know exactly how many subscribers will need to listen to the message before it can be completed.
https://medium.com/awesome-azure/azure-difference-between-azure-service-bus-queues-and-topics-comparison-azure-servicebus-queue-vs-topic-4cc97770b65
I am working to port an application which was designed to work in a non-Azure environment. One of the elements of the architecture is a singleton which does not scale, and which I'm hoping to replace w/ multiple worker processes serving the resource that the singleton currently provides.
I have the necessary changes in place to replace the singleton, and am at the point of constructing the communications framework to provide interconnection from the UI servers to the resource workers and I'm wondering if I should just use a TCP binding on a WCF service or whether using the Azure Service Bus would make more sense. The TCP/WCF is easy, but doesn't solve the complete problem: how do I ensure that only one worker processes a UI request?
From reading the available documentation, it sounds like the service bus will solve this, but I've yet to see a concrete example of implementation. I'm hoping someone here can assist and/or point me in the right direction.
Seems that Azure Service Bus queues are the right solution for you.
Azure Service Bus can be used in 3 different ways:
Queues
Topics
Relays
From windows azure site:
Service Bus queues provide one-way asynchronous queuing. A sender sends a message to a Service Bus queue, and a receiver picks up that message at some later time. A queue can have just a single receiver
You can find more info at:
http://www.windowsazure.com/en-us/develop/net/fundamentals/hybrid-solutions/
Adding to Davide's answer.
Another alternative would be to use Windows Azure Queues. They are designed to facilitate asynchronous communication between web and worker roles. From your web role you push messages into a queue which is polled by your worker roles.
Your worker role can "Get" one or more messages from a queue and work on those messages. When you get a message from a queue, you can instruct the queue service to make those messages invisible to other callers for a certain amount of time (known as message visibility timeout). That would ensure that only worker role instance get to work on a message.
Once the worker role has completed the work, it can simply delete the message. If there's an error in processing the message, the message automatically reappears in the queue once the visibility timeout period has expired. You may find this link helpful: http://www.windowsazure.com/en-us/develop/net/how-to-guides/queue-service/.
Azure queues are not designed for inter process communication, but inter-application communication. The message delivery latency is substantial, and delivery timing cannot be guaranteed. Websockets or NetTcpBinding is more suitable for applications that talk to eachother in realtime. Although must admit, you get some free stuff with queuez, especially the locking mechanisms. Just my 2 cents