Sender-selected distribution from web-management

[Gotthard, Petr]

Hello,

 

Is the sender-selected distribution (CC and BCC) supposed to work from the web-management? When I publish a message (via web-management) to an exchange and I set key1 as the RK and then key2 in a “CC” header (as list of strings), the message gets routed to key1 only. No error is reported.

 

Is this supposed to work?

 

Thanks,

Petr

[Michael Klishin]

On 28 November 2014 at 01:12:00, Gotthard, Petr (petr.g...@honeywell.com) wrote:
> Is the sender-selected distribution (CC and BCC) supposed
> to work from the web-management? When I publish a message (via
> web-management) to an exchange and I set key1 as the RK and then
> key2 in a “CC” header (as list of strings), the message gets routed
> to key1 only. No error is reported.

I see a 406 PRECONDITION_FAILED. CC should not have any limitations, I suspect
this may be a form-to-headers translation issue. 
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[Simon MacMullen]

Hmm, works for me. Here is a picture of how I just published to three
queues via the default exchange:

http://imgur.com/36LY1W7

Note that the CC header must be a list of strings. This message was
published to the "test", "test1" and "test2" queues.

Cheers, Simon

[Michael Klishin]

 On 28 November 2014 at 01:36:13, Simon MacMullen (si...@rabbitmq.com) wrote:
> Hmm, works for me. Here is a picture of how I just published to
> three
> queues via the default exchange:
>
> http://imgur.com/36LY1W7
>
> Note that the CC header must be a list of strings. This message
> was
> published to the "test", "test1" and "test2" queues.

Ah, yes, it works when using a list. I was using a comma-separated list.

[Gotthard, Petr]

I see the problem now: I have one queue with multiple bindings.

When there is a queue with multiple bindings, or a wildcard matching multiple CC entries, the sender-selected distribution with CC to r1, r2 and r3 is not(!) equivalent to sending three messages with RK r1, r2, r3.

From a user perspective this was not obvious to me. If this is the correct behavior, I'd suggest to update the documentation (http://www.rabbitmq.com/sender-selected.html) and say that the message will not get duplicated when multiple CC entries are matching the destination.


Sometimes the destination queue is not the final destination and the consumer is using the RK to determine the next hop / further processing. The BCC field is particularly useless in this case because the consumer gets one message only (because it has only one queue) with the BCC field removed (to preserve confidentiality), so the consumer will not know what was the intended final destination indicated in the BCC.

This is the dark side of this "non-duplicating" CC and BCC. This is probably a feature, not a bug. I just wanted to report this so other don't fall in the same trap. ;-)


Cheers,
Petr

--
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.

[Simon MacMullen]

On 29/11/14 10:16, Gotthard, Petr wrote:
> I see the problem now: I have one queue with multiple bindings.
>
> When there is a queue with multiple bindings, or a wildcard matching
> multiple CC entries, the sender-selected distribution with CC to r1,
> r2 and r3 is not(!) equivalent to sending three messages with RK r1,
> r2, r3.

No, it's not.

> From a user perspective this was not obvious to me. If this is the
> correct behavior, I'd suggest to update the documentation
> (http://www.rabbitmq.com/sender-selected.html) and say that the
> message will not get duplicated when multiple CC entries are matching
> the destination.

Yeah, that might be worth doing. Note that this is not specific to
sender-selected distribution though; if you bind a topic exchange to a
queue with "a.#", "a.b.#" and "a.b.c" and then publish "a.b.c" it will
only get routed to the queue once. In fact internally there are a few
places where we assume each message can only get routed to a queue once.

> Sometimes the destination queue is not the final destination and the
> consumer is using the RK to determine the next hop / further
> processing. The BCC field is particularly useless in this case
> because the consumer gets one message only (because it has only one
> queue) with the BCC field removed (to preserve confidentiality), so
> the consumer will not know what was the intended final destination
> indicated in the BCC.
>
> This is the dark side of this "non-duplicating" CC and BCC. This is
> probably a feature, not a bug. I just wanted to report this so other
> don't fall in the same trap. ;-)

Yeah, it is I'm afraid.

Cheers, Simon