As per my understanding RabbitMQ server by default creates exchange of type Direct i.e If I create exchange without providing any type it will create exchange of type Direct.Is there any way by which I can change default behavior i.e default exchange type as fanout instead of Direct i.e if exchange type is missing then exchange should be of type Fanout notDirect
No, this isn't configurable, but there is a default fanout exchange that is also created.
Related
Is there a way to configure some policy to redirect messages from one exchange to another exchange, if the current exchange doesn't have any binded queue?
I got a situation where RabbitMQ after restart loose some bindings and my messages were gone.
Yes, the feature is called Alternate Exchanges, and it works like this:
You set a "policy" which matches exchange A, with a key of 'alternate-exchange' and a value naming exchange B. Alternatively, you can set it as a property directly when creating the exchange.
Any message routed to exchange A which doesn't match any binding will be routed to exchange B.
Exchange B processes it in the normal way, and can even have an Alternate Exchange of its own.
I have just learned I have a high number of unroutable messages being published to the default exchange.
Because this is the default exchange, I am having a hard time tracking down the source of these unroutable messages. If this was not the default exchange I could find the publishing client by searching my code base by exchange name. Additionally, I can't effectively bind to the default exchange because I do not know the routing keys of the messages being published.
Is there any way I can find these messages without starting/stopping all my clients one at a time?
Is it possible to have some "default" queue for a rabbitmq exchange with a type 'direct'?
Like, i have an exchange A and queues Q1,Q2,Q3,QDef . so if somethign is published with routing key Q1. it will go to to Q1.
But if a message is with a routing key Q4 then it should go to QDef.
If routing key is not name of existent queue then a message should go to QDef.
Is it possible to do with a rabbitmq? Maybe exchange should not be of a type 'direct' but some other type?
With other words.
If some consumer declared a queue for some routing key then messages should go to this queue. If not then messages should go to a default consumer.
You can obtain the intended behavior by using and alternate exchange (AE).
So you should define the AE for you exchange A and bind your queue QDef to it. Unroutable messages will be delivered to it.
I have exactly 2 types of messages that I want to be sent via RabbitMQ. So I have 2 options how I can do this:
sent a message to default empty-named exchange with routing_key corresponding to the queue name
use direct exchange's routing_key parameter corresponding to consumer's routing_key parameter in queue binding
So which option is preferable and why?
A default exchange is a direct exchange. RabbitMQ creates the default exchange by default, but it uses an empty string for the name. If you look at the RabbitMQ AMQP concepts page, under Default Exchange:
The default exchange is a direct exchange with no name (empty string)
pre-declared by the broker.
You can see this by running rabbitmqctl list_exchanges as well:
direct
Foo direct < Same thing as the above
amq.direct direct
amq.fanout fanout
...and so on
As far as I'm aware, there isn't any benefits of using one over the other. I would stick with the default exchange if you only need to route based on routing keys.
Let's say you direct-bind to an exchange broadcasting logs to routing keys of "info", "warn", and "error". Using the default exchange, you would need to create three different queues with those names to receive all logs; and adjustments to which log levels you receive would require changing your queue declarations. By using a named exchange, you can simply change your queue's bindings and continue processing things as normal.
In short, it provides one extra level of abstraction.
As I see it, the default direct exchange give the possibility for the consumers and the producers to not know about each other, by binding a queue (used by a consumer) to an exchange (used by a producer) implicitly using the queue's name.
I use the default direct-exchange for a specific case: the consumer and producers don't know about each other. In my case, each consumer have its proper queue. From the producer, I cannot know by advance which queues are going to be declared and used, as it depends on the consumers. So it is impossible to define the bindings between a custom direct-exchange and the queues on the producer side.
One way to solve it with a custom (user-defined) direct-exchange would be to define the binding-key on consumer side. But it would means to know about the producer from the consumer side as I need to know the exchange name used by the producer.
Therefore, automatically binding a queue by its name on the default direct-exchange makes it possible, in my case, to only declare a queue on consumer side and send message to it from producer by only knowing the queue's name.
Of course it implies to know the queue's name at runtime, when invoking the producer, as it would be required to know the binding-key of a custom direct-exchange (in my case, the queue's name is given by the application using the producer). But when configuring the broker, producers and consumers don't have to know about each other.
some description in rabbitmq web manager.
//default exchange 's Bindings
Default exchange
The default exchange is implicitly bound to every queue,
with a routing key equal to the queue name.
It is not possible to
explicitly bind to, or
unbind from the default exchange.
It also cannot be deleted.
I'm looking for a way to secure my websites messaging system so that users only get data they should have access to. With this in mind, I thought of a system where I have a master topic exchange which my server will send all messages to.
The web site holds a sessionId for each user. When a user is authenticated, another exchange is created with a name of sessionId. The client side user is allowed to bind to all exchanges other then the master. Since sessionID's are unique it would be very hard to guess another users sessionID and bind to get their messages.
each message will have a routing key of sessionID.destination. The client side will know all of the potential destinations.
To help visualize:
-> SessionID Exchange -> client
Server -> master Exchange | -> SessionID Exchange -> client
-> SessionID Exchange -> client
My question is two fold. Is it possible to bind an exchange to an exchange in rabbitmq? Also, has someone set up a system like this one previously? Rather, does anyone with experience on this topic already have a working system which I may use?
Thanks in advanced.
Yes it is possible to bind and exchange to and exchange. You can even have different types of exchanges. You need to used channel.exchangeBind() instead of channel.queueBind(). But it works in a similar way.
I have a topic exchange bound to a fanout exchange in my system. I make sure to send a routing key with the messages sent to the fanout exchange. Its no effect at the fanout exchange level but when it gets routed to the topic exchange the routing key is then used to determine which queues it is sent to.
I found this blog which talked about something similar to my design. It's not quite the same thing, but it let's me know that it's at least possible.
http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/
In case of single exchange and multiple queues bound, messages sent by client will reach via exchange to possible queues based upon bindings.Which means message from client will reach destination queue via exchange in one hop.
Consider a case where you want messages to be sent to possible destination queues based upon bindings, ALSO take more hops to different exchange and its queue bound. In such cases exchange to exchange binding will fit the purpose.
Binding queue to exchange is a costly process.Exchange to exchange binding is more flexible and a better scalability solution. Client can create its own private exchange and bind to special purpose exchange at the server. Exchange to exchange binding is better in performance and solves scalability issues.