Thanks for your suggestion and the comment regarding send-to-dla-on-no-route.
I will probably use your approach. However, I did try to do a little adjustment
by defining the DLQ address like this (since that appears to be similar to how
auto-create-dead-letter-resources creates queues when set to true):
<address name="DLQ">
<multicast>
<queue name="DLQ.TEST.QUEUE.A">
<filter string="NOT(MyMessageProperty='SYSTEM_X') AND
NOT(MyMessageProperty='SYSTEM_Y')"/>
</queue>
</multicast>
</address>
The divert is forwarding to that queue using the fully qualified queue name
DLQ::DLQ.TEST.QUEUE.A like this:
<forwarding-address>TEST.QUEUE.A.SYSTEM_X,TEST.QUEUE.A.SYSTEM_Y,DLQ::DLQ.TEST.QUEUE.A</forwarding-address>
When sending a message with MyMessageProperty set as “dummy” it ends up on
DLQ::DLQ.TEST.QUEUE.A. However, when setting MyMessageProperty as “'SYSTEM_X”
the message ends up on both TEST.QUEUE.A.SYSTEM_X and DLQ::DLQ.TEST.QUEUE.A.
When not using the fully qualified queue name and instead forwarding to an
address with an anycast queue using the exact same filter expression, the
message with MyMessageProperty set as “'SYSTEM_X” won’t end up on that queue.
Is this a bug or expected behaviour? Should fully qualified queue names be
avoided when configuring forwarding-address?
Regards,
Calle
