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
Related
I’m new to ActiveMQ.
I’m accessing a topic from ActiveMQ using C# code. Does the subscription to the topic need to be active all the time when the messages arrive? When the messages arrive in topic and if the subscriber is not active then will I get the message when I start the subscription service later?
Traditional publish/subscribe semantics dictate:
The subscription has to exist before the messages are sent.
You will not receive messages sent previously when you create the subscription later.
This is true for both durable and non-durable subscriptions.
By default a subscription is non-durable and only receives messages while the susbsciber is active.
Howeve, a durable subscription will receive messages even if the subscriber is inactive. This can be helpful so as to not miss messages if the subscriber drops offline for a short time, but if the subscriber drops offline for a long time then messages may accumulate and consume an inordinate amount of resources.
Sounds like you are looking for a 'Durable Subscription'. This creates a subscription on the broker, so the consumer will receive any messages regardless if connected at the time the message is published.
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.
Is it possible for topics to have one subscriber for dead letters which themselves are being generated from multiple subscribers themselves?
E.g. two subscribers to a topic, sub-a and sub-b, if either of them generate a dead-letter, a subscriber "sub-deadletter" should pick it up. Is this possible?
The context of all of this is an C# azure function
You can use the ForwardDeadLetteredMessagesTo property of the topic Subscriptions and topic subscription rules to bring you required functionality.
1.You need to set the ForwardDeadLetteredMessagesTo property of each topic subscription to the same Service Bus Topic to which the topic subscriptions belong.
2.Create a Topic Subscription rule for the topic subscription that should process your dead-lettered messages, with a correlation filter to receive only the dead-lettered messages.
A combination of both these features of Azure service Bus Topic Subscriptions should solve your problem.
Is possible to use topic exchange as true event notification system?
I've created topic exchange on given exchange named as Cherry. I've got one publisher at routing key cherry.user.created and many consumers with same routing key, but when I publish an event only one of consumers consume an event. I thought that topic can be used as "real event broadcasting" - every consumer gets notified when given event happened, but right now only one consumer consume an event and other consumers do not know about created event...
To clarify my comment about queues. In rabbitmq, if multiple consumers use the same queue - message delivered to that queue is always dispatched in round-robin manner, no matter what. So when you subscribe to topic exchange, best way is to declare new queue for each consumer (with any name, or better random generated by rabbit itself) and use target routing key (cherry.user.created) to bind those queues to exchange.
I successfully setup a Topic Exchange, and I'm able to deliver messages to several consumers at once.
I'd also like to deliver messages to competing consumers and keep using topic exchanges. I read that using the same queue name enables consumers to compete for messages. I might be mistaken, however, since I cannot make it work.
Setup for several listeners to the same topic:
Declare topic exchange
For each listener, declare a new queue with an autogenerated name
Bind this queue to the above exchange with a given topic routing key
How to setup competing consumers to the same topic?
Is it even possible with Topic Exchanges?
Thanks.
Let's review a couple of points first.
First, remember that in RabbitMQ you always consume from queues. Exchanges are just your portals and you cannot directly consume from them.
Second, Topic exchanges allow for binding the queues with routing key "patterns". Therefore, the term topic is valid in the context of "Topic Exchanges".
Now this is what I understand from your question:
Multiple consumers/same routing key:
This is where you want multiple consumers to all consume the messages with the same routing key (or same routing key patterns in the case of Topic Exchanges). This is in fact doable. Just do this:
Declare your Topic Exchange
Declare a queue with some name
Bind that queue to your topic with your desired routing key pattern
Create multiple consumers and have them listen to that same queue.
What will happen is that RabbitMQ is going to load balance to your consumers in a round robin matter. This means all consumers will consume from the same queue. But remember that in this scenario it is possible that a single message is delivered more than once in theory.
What you were doing was to create multiple queues and have one consumer per queue. This means that every message coming to the exchange would be duplicated across all queues. The end result would be that a message gets processed multiple time.
I solved this by using exchange-to-exchange bindings.
The outer exchange is a topic exchange.
The inner exchange is a fanout exchange bound to a client-named queue.
The outer exchange is bound to the inner exchange with a routing key that includes a wildcard.