Binding to header exchanges

[Stuart Longland]

Hi all,

Silly question. I'm trying to figure out a state machine framework for
interacting with AMQP so that I can develop a set-and-forget AMQP client.

The concept is that the application creates whatever queue and exchange
objects, binds them, sets them up to consume, pushes messages to them, etc.

The mechanics of opening channels, declaring objects, then binding and
consuming queues is looked after by state machines. Fire and forget.
If there's a problem, we get notified by a callback mechanism.

For simple cases, this isn't too hard. Direct exchanges, fan-out and
topic exchanges are no problem here. I have a simple scheme wherein the
topics for an exchange are stored in 3 sets: one storing my currently
bound topics, one for topics that are to be bound and one for topics
that are to be unbound.

On receipt of a 'declare-ok', 'bind-ok' or 'unbind-ok', I can look
through my to-bind or to-unbind sets, pick one off the list, and action
it: making a note of what we were just doing. When the reply comes
back, I update my state and proceed until the to-unbind and to-bind sets
are empty.

Then we get header exchanges.

One option is I make these sets dicts/maps/hashes/tables (whatever the
language calls them); mapping the routing key to the arguments.

Question is, is it valid to have multiple bindings of a queue to the
same header exchange with different arguments?

If the queue is already bound to the exchange with a given routing key,
does the 'bind' operation add/overwrite to the arguments previously
given, does it completely replace the old arguments, or would that throw
back an error because we're already bound to that exchange? (Or be
ignored?).

I realise the routing key is not used for making routing decisions, is
that key used for maintaining separate argument tables or is it
completely ignored by the broker?

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

[Alvaro Videla]

Hi,

You can bind a queue multiple times to the same exchange using different headers/routing keys (depends on what's used by the exchange type).

The headers exchange ignores routing keys and only acts on headers.

Cheers,

Alvaro

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send an email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stuart Longland]

Hi Alvaro,

On 16/04/15 08:45, Alvaro Videla wrote:
> You can bind a queue multiple times to the same exchange using different
> headers/routing keys (depends on what's used by the exchange type).
>
> The headers exchange ignores routing keys and only acts on headers.

Ahh okay so it's a separate set of headers per routing key. So what
happens if I'm bound with a key of 'foo', and I send a second bind with
that same key?

Does the new 'bind' overwrite the old one or are they merged somehow?

What does 'unbind' mean in regards to arguments?

[Stuart Longland]

On 16/04/15 09:13, Stuart Longland wrote:
> Hi Alvaro,
> On 16/04/15 08:45, Alvaro Videla wrote:
>> You can bind a queue multiple times to the same exchange using different
>> headers/routing keys (depends on what's used by the exchange type).
>>
>> The headers exchange ignores routing keys and only acts on headers.
>
> Ahh okay so it's a separate set of headers per routing key. So what
> happens if I'm bound with a key of 'foo', and I send a second bind with
> that same key?
>
> Does the new 'bind' overwrite the old one or are they merged somehow?

I just did some testing of my own. Seems I just get two separate
bindings for the key 'foo'.

So to represent this, looks as if it'll be a map storing lists of maps. i.e.

Map<Key, List< Map<Argument, Value> > >

[Alvaro Videla]

The binding DB table is a set so my understanding is that bindings are overwritten if they have the same arguments (exchange, queue and routing key or headers).

To perform an unbind you must pass the same arguments as well.

[Alvaro Videla]

On Thu, Apr 16, 2015 at 1:23 AM Stuart Longland <stu...@longlandclan.yi.org> wrote:

I just did some testing of my own.  Seems I just get two separate
bindings for the key 'foo'.

 Would you mind sharing how you performed the test? Most programs using RabbitMQ have a series of queue declare, exchange declare, and bind commands that are executed every time the script is run. The same if the script is run multiple times, to have parallel workers for instance. That said, people don't end up with duplicated bindings. If that were the case then at some point RabbitMQ would run out of disk space due to duplicate bindings.

[Stuart Longland]

On 16/04/15 09:35, Alvaro Videla wrote:
> Would you mind sharing how you performed the test? Most programs using
> RabbitMQ have a series of queue declare, exchange declare, and bind
> commands that are executed every time the script is run. The same if the
> script is run multiple times, to have parallel workers for instance.
> That said, people don't end up with duplicated bindings. If that were
> the case then at some point RabbitMQ would run out of disk space due to
> duplicate bindings.

I didn't write any code, I just used the RabbitMQ management interface
to create a queue, then bind it multiple times.

Attached is what I was left with.

[Alvaro Videla]

Ok. But there in the pic all your bindings are different, so it is expected that you will end up with three bindings in this case.