[rabbitmq-discuss] Query for Binding with similar topic routing keys returns all similar vs the one matching

[Simon MacMullen]

On 12/10/11 15:48, Helena Edelson wrote:
> Matthias,

Hi Helena. I've figured out what's happening.

> Given the following precondition:
> Bindings exist that routing keys such as #.foo.bar and *.foo.bar would match.
> Where objOption is the Option returned from GET /api/bindings/vhost/e/exchange/q/queue/routingKey  which unfortunately is either a binding or an array of bindings matching the #etc pattern

There are a couple of issues here. One is that the path should not be 
/api/bindings/<vhost>/e/<exchange>/q/<queue>/<routing_key>, it's 
/api/bindings/<vhost>/e/<exchange>/q/<queue>/<properties_key>, where 
properties_key is a name for the binding the management plugin generates 
from the routing key *and the arguments*. The properties key will often 
look like the routing key in simple cases, but as soon as there are 
arguments in the binding, or the routing key contains some special 
characters, it will differ. This is all to get round the fact that 
bindings don't have names, unlike everything else in AMQP.

You can see the properties key for a given binding when retrieving its 
details from mgmt.

The other issue is that in general any names that are in the URI need to 
be URI-escaped - in the same way as the vhost "/" needs to be referred 
to as "%2F", since some characters that are valid in AMQP cannot appear 
in URIs.

...and of course '#' is such a character - it marks the start of the 
fragment in a URI, so when you request:

/api/bindings/vhost/e/exchange/q/queue/#.foo.bar

You're really asking for the document 
"/api/bindings/vhost/e/exchange/q/queue/" (i.e. the list) and asserting 
that you're going to look at the bit of it identified by ".foo.bar". I'm 
not sure whether your HTTP client or Mochiweb / Webmachine strip the 
fragment part out, but that's what's happening.

Anyway: tl;dr - use the properties key. If you need to generate such a 
key then it has the form:

enc(routing_key) + "_" + enc(args_key_n) + "_" + enc(args_value_n) + "_" 
+ enc(args_key_2) + "_" + enc(args_value_2) ... etc

where enc() means 'URI encode, additionally encoding "_" as "%5F"'.

Cheers, Simon

> Case 1: If I pass in binding pattern #.foo.bar, I get an array of Bindings
> Case 2: If I pass in binding pattern *.foo.bar, I consistently get a single matching Binding
>
> Here is what I am doing, in scala, where I want to extract one binding given one pattern (routing key).
>
> if (objOption.isDefined) objOption.get match {
>
>     case bindings: Array[Binding] =>  for { b<- bindings if b.getRoutingKey == pattern } binding = b
>
>     case b: Binding =>  binding = objOption.get.asInstanceOf[Binding]
> }
>
>
> Helena
> ________________________________________
> From: Matthias Radestock [matthias at rabbitmq.com]
> Sent: Wednesday, October 12, 2011 7:21 AM
> To: Helena Edelson
> Cc: rabbitmq-discuss at lists.rabbitmq.com
> Subject: Re: [rabbitmq-discuss] Query for Binding with similar topic routing keys returns all similar vs the one matching
>
> Helena,
>
> On 11/10/11 14:15, Helena Edelson wrote:
>> I found the user of the # character in the pattern of the binding,
>> given the number and type of binding patterns between queues and
>> exchanges, consistently returns multiple results vs the * character
>> which Rabbit can return a singular match. So I had to write a work
>> around :-)
>
> So do you think there is something broken there in rabbit? Or perhaps
> less obvious than it could be? If so, an example of the form "I tried X
> and was expecting to see Y but instead got Z" would help to shed light
> on the problem.
>
> Matthias.
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


-- 
Simon MacMullen
RabbitMQ, VMware