Problem with multiple consumers using the same fully qualified queue name

Question

I have an address and a queue defined as following in broker.xml:

    <address-settings>
      ...
      <auto-create-queues>false</auto-create-queues>
      <auto-create-addresses>false</auto-create-addresses>
    </address-settings>
    <addresses>
      <address name="news.world">
        <multicast>
          <queue name="america.sport"/>
        </multicast>
      </address>
      ...

I spin two consumers (different sessions/connections) listening to news.world::america.sport and send a message to it. Only one consumer receives the message though.

With the auto-created addresses/queues each consumer gets its own queue (named with an uuid) and the message seems to be cloned to each of them, as a result both receive it. I want to avoid the message cloning due to the storage limitations and thought to achieve this by using a non auto created addresses/queues. I am wondering why a single "hardcoded" multicast queue actually behaves like anycast one.

Answer 1

Based on your description it appears to me that everything is working as designed.

Since you have 2 consumers sharing the same queue (i.e. america.sport on the address news.world) they will, of course, share the same messages. In other words, the messages in the queue will be distributed to one consumer or the other, not both. This is in accordance with the fundamental semantics of a queue.

The fact that the queue is multicast doesn't change the way messages from the queue are distributed to consumers. Multicast is a routing type and therefore only impacts how messages are routed from the address to the queue(s).

Also, the message "cloning" that you observe when a message sent to an address is put on every one of the multicast queues actually has very little overhead. You appear to think that the message on each queue is stored independently as if one message sent to 100 multicast queues on the same address is stored 100 times. This is not the case. The actual message (i.e. the body, headers, & properties) is only stored once and then each queue gets a "reference" to that message. The overhead of this reference is intentionally very small in order not to waste resources (i.e. memory or disk). If you have "storage limitations" then using multiple consumers on a single multicast queue is not the way to deal with them.