[rabbitmq-discuss] Bug/Behavior Change in binds to header exchanges in rabbitmq 3.1.0
matthias at rabbitmq.com
Mon May 6 18:20:45 BST 2013
On 03/05/13 16:19, Matt Campbell wrote:
> In rabbit 3.0.4 and 2.8.7, I was able to bind a queue to a headers
> exchange without specifying any bind arguments, which resulted in that
> queue receiving all the messages. In rabbit 3.1.0, when I make that same
> bind I get an error message telling me I must include the "x-match"
> header. While this is an irritation for clients that use AMQP or the
> HTTP API to create the binds (because they require a code change), I
> have some clients that bind queues to this exchange via STOMP and I am
> unaware of how to get that header set through a STOMP subscribe to that
> Is this an intended behavior change going forward, or is this a bug in
> rabbitmq 3.1.0?
We introduced validation of the x-match header in 3.1 - a change that
unfortunately didn't get mentioned in the release notes.
As part of that, bindings with no x-match header are now rejected
whereas previously they would be treated as 'all' matches.
The spec is vague in this regard; it neither says that x-match must be
present nor what should happen when it isn't.
I have filed a bug to explore whether we should revert to the original
behaviour, though given the spec vagueness it is probably best not to
depend on that in applications.
As an alternative to changing the bindings in your code, you could
introduce an intermediate fanout exchange, either
a) in front of the headers exchange, with publishers publishing to that
instead of the headers exchange, or
b) behind the headers exchange, bound to it with x-match=all, so that
selected queues can bind to that w/o having to set a header
More information about the rabbitmq-discuss