[rabbitmq-discuss] RabbitHub: Binding a queue to an exchange

Michael Bridgen mikeb at lshift.net
Thu Feb 4 14:04:00 GMT 2010

> The principle of subscribing a queue to an exchange makes sense in my 
> opinion and so I tried it but it didn't work. The problem seems to be 
> the verification ('hub.verify'):
> 1) if left away      -> 400 Missing required parameter
> 2) if set to 'sync'  -> 400 Request verification failed
> 3) if set to 'async' -> 202 but the binding never shows up (checked
>    with 'sudo rabbitmqctl list_bindings'

Part of the "endpoint" facet is the ability to generate tokens for this 
purpose.  This isn't part of the PubSubHubBub spec, but necessary 
because of the way RabbitHub generalises from it.

So in theory[1] you'll need something like

which will respond with a token which you can then use as 
hub.verify_token when you subscribe.
(You may well have discovered this, but in general, if you browse to a 
RabbitHub URL you'll get API documentation)

[1] I just tried this myself locally, and it doesn't appear to work as 
I've described -- but I may have got quoting or something wrong, or be 
running some freaky experimental revision of rabbitmq-server, so please 
do try yourself.
Hence or otherwise I'm going to have a bit more of a look at the code.


> I am directing the POST to
>   http://localhost:8000/subscribe/x/exchange_OrderEvent_shop1
> with
> hub.callback equal to
>   http://localhost:8000/endpoint/q/queue_ShopCheckout
> and
> hub.topic equal to
>   shop1
> Any idea what's wrong?
> Oliver
> Michael Bridgen wrote:
>  > As I understand it, you subscribe the queue's endpoint facet (something
>> like ../rabbithub/endpoint/q/some_queue_name) to the exchange's 
>> subscription facet (something like 
>> /rabbithub/subscribe/x/some_queue_name).
>> In other words, you POST to the latter, with hub.callback set to the 
>> former and hub.mode "subscribe" (and hub.topic as the binding key), as 
>> in 
>> http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html#anchor5 
>> RabbitHub is smart enough to recognise that the URLs are an exchange 
>> and a queue that it controls, and will create a normal AMQP binding.  
>> You can subscribe exchanges and queues in other combinations, but it 
>> won't correspond to an AMQP binding -- in these cases RabbitHub will 
>> make Other Arrangements.
>> HTH
>> Michael

More information about the rabbitmq-discuss mailing list