You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Berge Stillingen (JIRA)" <ji...@apache.org> on 2016/09/09 09:15:21 UTC
[jira] [Updated] (AMQ-6424) Duplicate dead letter queues using
journaling
[ https://issues.apache.org/jira/browse/AMQ-6424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Berge Stillingen updated AMQ-6424:
----------------------------------
Description:
In version 5.14 (and 5.13.3) it appears the broker is able to 'occasionally' create extra DLQ-queues holding duplicate messages.
Browsing the admin console, you will sometimes see something like this:
- DLQ.myEventQueue
- DLQ.DLQ.myEventQueue
That both hold the samme message ID, eg. ID:ClientABC-61753-1471513949441-1:4:1:3:1
The one from DLQ.myEventQueue is a standard entry caused by a client transaction rollback.
The (unwanted) one from DLQ.DLQ.myEventQueue has a
- dlqDeliveryFailureCause: java.lang.Throwable: duplicate paged in from store for queue://DLQ.myEventQueue
At some point you can even get a third queue named
- DLQ.DLQ.DLQ.myEventQueue holding another message with the samme MessageID and the same dlqDeliveryFailureCause
Reproduce: Haven't found a way to provoke the error. It happens occasionally in a semi-active test environment running with Mule 3.6.2.
Best guess is that there is some issue with the use of Journaling and synchronization between Kahadb and the MSSQL-database.
Configuration can be found at
http://activemq.2283324.n4.nabble.com/file/n4715868/activemq-anonymous.xml
was:
In version 5.14 (and 5.13.3) it appears the broker is able to 'occasionally' create extra DLQ-queues holding duplicate messages.
Browsing the admin console, you will sometimes see something like this:
- DLQ.myEventQueue
- DLQ.DLQ.myEventQueue
That both hold the samme message ID, eg. ID:ClientABC-61753-1471513949441-1:4:1:3:1
The one from DLQ.myEventQueue is a standard entry caused by a client transaction rollback.
The (unwanted) one from DLQ.DLQ.myEventQueue has a
- dlqDeliveryFailureCause: java.lang.Throwable: duplicate paged in from store for queue://DLQ.myEventQueue
At some point you can even get a third queue named
- DLQ.DLQ.DLQ.myEventQueue holding another message with the samme MessageID and the same dlqDeliveryFailureCause
Reproduce: Haven't found a way to provoke the error. It happens occasionally in a semi-active test environment running with Mule 3.6.2.
Best guess is that there is some issue with the use of Journaling and synchronization between Kahadb and the MSSQL-database. Configuration file is attached
> Duplicate dead letter queues using journaling
> ---------------------------------------------
>
> Key: AMQ-6424
> URL: https://issues.apache.org/jira/browse/AMQ-6424
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, KahaDB
> Affects Versions: 5.13.3, 5.14.0
> Reporter: Berge Stillingen
> Labels: database, journal, mssql
>
> In version 5.14 (and 5.13.3) it appears the broker is able to 'occasionally' create extra DLQ-queues holding duplicate messages.
> Browsing the admin console, you will sometimes see something like this:
> - DLQ.myEventQueue
> - DLQ.DLQ.myEventQueue
> That both hold the samme message ID, eg. ID:ClientABC-61753-1471513949441-1:4:1:3:1
> The one from DLQ.myEventQueue is a standard entry caused by a client transaction rollback.
> The (unwanted) one from DLQ.DLQ.myEventQueue has a
> - dlqDeliveryFailureCause: java.lang.Throwable: duplicate paged in from store for queue://DLQ.myEventQueue
> At some point you can even get a third queue named
> - DLQ.DLQ.DLQ.myEventQueue holding another message with the samme MessageID and the same dlqDeliveryFailureCause
> Reproduce: Haven't found a way to provoke the error. It happens occasionally in a semi-active test environment running with Mule 3.6.2.
> Best guess is that there is some issue with the use of Journaling and synchronization between Kahadb and the MSSQL-database.
> Configuration can be found at
> http://activemq.2283324.n4.nabble.com/file/n4715868/activemq-anonymous.xml
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)