[
https://issues.apache.org/jira/browse/AMQ-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15145546#comment-15145546
]
Timothy Bish commented on AMQ-6162:
-----------------------------------
I dug a little deeper and the issue is that the setup you have were the message
passes through multiple DLQ's makes it quite tricky to not capture the message
as a duplicate when it passes through the chain of Queues again. The move does
rollback the message from the audit of DLQ2 but the broker doesn't know that
the message was previously in DLQ1 and so it can't run back through and remove
the message from the audit of that Queue. You can work around this by
disabling the Audit for your dead letter strategies which will prevent the
tiered DLQ's from filtering out the message on repeated cycles through them.
> DLQ'd message does not get DLQ'd again until broker restart
> -----------------------------------------------------------
>
> Key: AMQ-6162
> URL: https://issues.apache.org/jira/browse/AMQ-6162
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.13.0
> Reporter: Jo Vandermeeren
> Priority: Critical
> Attachments: AMQ6162Test.java
>
>
> Given the following setup: Q1 -> DLQ1 (dead letter for Q1) -> DLQ2 (dead
> letter for Q2).
> Sessions are transacted.
> 1. Send message to Q1
> 2. Consume Q1 and rollback
> 3. Message is DLQ'd to DLQ1
> 4. Consume DLQ1 and rollback
> 5. Message is DLQ'd to DLQ2
> 6. Move message via JMX from DLQ2 to Q1 (QueueViewMBean.moveMessageTo())
> 7. Consume Q1 and rollback
> 8. DLQ1 stays empty, message seems lost
> If you restart the broker between step 5 and step 6, the message does get
> DLQ'd to DLQ1 again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
