Here's what I would suggest:

      <addresses>
         ...
         <address name="TEST.QUEUE.A">
           <anycast>
               <queue name="TEST.QUEUE.A"/>
            </anycast>
         </address>
         <address name="TEST.QUEUE.A.SYSTEM_X">
            <anycast>
               <queue name="TEST.QUEUE.A.SYSTEM_X">
                  <filter string="MyMessageProperty='SYSTEM_X'"/>
               </queue>
            </anycast>
         </address>
         <address name="TEST.QUEUE.A.SYSTEM_Y">
            <anycast>
               <queue name="TEST.QUEUE.A.SYSTEM_Y">
                  <filter string="MyMessageProperty='SYSTEM_Y'"/>
               </queue>
            </anycast>
         </address>
         <address name="DLQ.HANTERAUTSKICK.UTSKICKSBEGARAN.REPLY">
            <anycast>
               <queue name="DLQ.HANTERAUTSKICK.UTSKICKSBEGARAN.REPLY">
                  <filter string="NOT(MyMessageProperty='SYSTEM_X') AND
NOT(MyMessageProperty='SYSTEM_Y')"/>
               </queue>
            </anycast>
         </address>
      </addresses>

      <diverts>
         <divert name="COMPOSITE-TEST.QUEUE.A">
            <address>TEST.QUEUE.A</address>

<forwarding-address>TEST.QUEUE.A.SYSTEM_X,TEST.QUEUE.A.SYSTEM_Y,DLQ.HANTERAUTSKICK.UTSKICKSBEGARAN.REPLY</forwarding-address>
            <exclusive>true</exclusive>
         </divert>
      </diverts>

This gets you essentially the exact behavior you had before, including with
the DLQ, and you don't have to configure any extra address settings.

For what it's worth, setting send-to-dla-on-no-route to true on # is going
to cause problems (e.g. the extra notification messages in the DLQ). This
kind of configuration is not recommended since dropping messages that have
no route is standard practice for multicast (i.e. pub/sub) use-cases.

Hope that helps.


Justin

On Mon, Oct 16, 2023 at 3:42 PM Calle Andersson <calleanders...@hotmail.com>
wrote:

> I have an old A-MQ with a lot of composite queues, e.g:
> <compositeQueue name="TEST.QUEUE.A">
> <filteredDestination selector="MyMessageProperty='SYSTEM_X'"
> queue="TEST.QUEUE.A.SYSTEM_X" />
> <filteredDestination selector="MyMessageProperty='SYSTEM_Y'"
> queue="TEST.QUEUE.A.SYSTEM_Y" />
> <filteredDestination selector="NOT(MyMessageProperty='SYSTEM_X') AND
> NOT(MyMessageProperty='SYSTEM_Y')
> queue="DLQ.HANTERAUTSKICK.UTSKICKSBEGARAN.REPLY" />
> </compositeQueue>
>
> Currently, I'm investigating how to migrate to Artemis. The
> implementations of the existing clients (which sends and receives messages)
> should not be adjusted (i.e. the names of the queues should be the same and
> the clients should continue communicating via queues, not topics).
>
> I have defined the following addresses/queues in broker.xml:
> <address name="TEST.QUEUE.A">
>                           <anycast>
>                                                        <queue
> name="TEST.QUEUE.A" >
>
>           <filter string="UnwantedProperty='ShouldNeverMatch'"/>
>                                                        </queue>
>                           </anycast>
> </address>
> <address name="TEST.QUEUE.A.SYSTEM_X">
>                           <anycast>
>                                                        <queue
> name="TEST.QUEUE.A.SYSTEM_X" />
>                           </anycast>
> </address>
> <address name="TEST.QUEUE.A.SYSTEM_Y">
>                           <anycast>
>                                                        <queue
> name="TEST.QUEUE.A.SYSTEM_Y" />
>                           </anycast>
> </address>
> <address name="DLQ">
>                           <anycast>
>                                                        <queue name="DLQ" />
>                           </anycast>
> </address>
> <address name="ExpiryQueue">
>                           <anycast>
>                                                        <queue
> name="ExpiryQueue" />
>                           </anycast>
> </address>
>
> I also added the following diverts:
> <divert name="TEST.QUEUE.A.SYSTEM_X-divert">
>
> <routing-name>TEST.QUEUE.A.SYSTEM_X-divert</routing-name>
>                           <address>TEST.QUEUE.A</address>
>                           <filter string="MyMessageProperty='SYSTEM_X'"/>
>
> <forwarding-address>TEST.QUEUE.A.SYSTEM_X</forwarding-address>
>                           <exclusive>true</exclusive>
> </divert>
> <divert name="TEST.QUEUE.A.SYSTEM_Y-divert">
>
> <routing-name>TEST.QUEUE.A.SYSTEM_Y-divert</routing-name>
>                           <address>TEST.QUEUE.A</address>
>                           <filter string="MyMessageProperty='SYSTEM_Y'"/>
>
> <forwarding-address>TEST.QUEUE.A.SYSTEM_Y</forwarding-address>
>                           <exclusive>true</exclusive>
> </divert>
>
> And I also configured this for <address-setting match="#"> (in an attempt
> to make any messages not diverted by any divert to end up on a DLQ
> associated with the queue):
> <send-to-dla-on-no-route>true</send-to-dla-on-no-route>
> <dead-letter-address>DLQ</dead-letter-address>
> <dead-letter-queue-prefix>DLQ.</dead-letter-queue-prefix>
> <auto-create-dead-letter-resources>true</auto-create-dead-letter-resources>
> <max-delivery-attempts>1</max-delivery-attempts>
>
> Everything else is configured in the same way as in a newly created 2.31.0
> broker.
>
> Since I added a dummy filter to the TEST.QUEUE.A queue, I hoped that
> messages which doesn't get filtered to any queues or get diverted by any
> divert (e.g. if MyMessageProperty is missing or has an unexpected value)
> should be considered as undeliverable and end up on a newly created queue
> named "DLQ.TEST.QUEUE.A". To test this, I send messages to "TEST.QUEUE.A"
> in the following way (the “admin” user has all permissions):
> [ARTEMIS_HOME]/bin/artemis producer --message ipsum --message-count 1
> --destination TEST.QUEUE.A --url tcp://localhost:61616 --user admin
> --password admin
>
> However, the original messages simply disappears but for each message
> sent, there are 6 messages placed on the "DLQ" queue. All messages are
> empty. In 3 of them, "_AMQ_NotifType" have been set to "SESSION_CREATED".
> In the rest, "SESSION_CLOSED" are set.
>
> Could anyone explain the result and why it differs from my assumptions?
> Have I misunderstood some parts of the configuration or does some
> configurations not work together?
>
> Is there better ways to achieve what I'm trying to do?
>
> Regards,
> Calle
>

Reply via email to