good catch, reading back on AMQ-7067 I see that both xa and local commits were considered but only xa was completed! see: https://issues.apache.org/jira/browse/AMQ-7067?focusedCommentId=16643245&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16643245
this fix and test looks good. it may be good to open a new jira to track this case, b/c AMQ-7067 has been closed since 2018. On Tue, 23 Mar 2021 at 19:49, Jonathan Gallimore <jonathan.gallim...@gmail.com> wrote: > > Hi > > I've been looking at a problem I ran into here where messages are consumed, > and acknowledged, but are then later redelivered to the consumer again > after a broker restart. > > The consumer is running with transacted sessions, and looking in KahaDB, I > can see a KAHA_REMOVE_MESSAGE_COMMAND, with the local transaction ID added > to the journal, and then a KAHA_COMMIT_COMMAND after it. Some time later, I > see the exact same KAHA_REMOVE_MESSAGE_COMMAND appended to the journal > again, with the exact same transaction information, but no > corresponding KAHA_COMMIT_COMMAND. This appears to follow a > KAHA_REWRITTEN_DATA_FILE_COMMAND. > > It looks like the ack compaction method is forwarding the acknowledgement, > but not the commit - it appears that the commit is only forwarded in the > case of an XA transaction. > > I notice that there are some tests around this in AMQ-7067. I've managed to > reproduce this with a further test case in AMQ8067Test.java, and I have > created a PR for this here: https://github.com/apache/activemq/pull/636, > and backported to 5.16.x https://github.com/apache/activemq/pull/637 and > 5.15.x. https://github.com/apache/activemq/pull/638 > > Are there other cases that should be tested around this? > > Thanks > > Jon
