[jira] [Updated] (AMQ-9435) KahaDB durable sub tracking breaks on duplicate messages
[ https://issues.apache.org/jira/browse/AMQ-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9435: Fix Version/s: 5.17.7 > KahaDB durable sub tracking breaks on duplicate messages > > > Key: AMQ-9435 > URL: https://issues.apache.org/jira/browse/AMQ-9435 > Project: ActiveMQ Classic > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.18.3, 6.0.1 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 5.17.7, 6.0.2 > > Time Spent: 20m > Remaining Estimate: 0h > > There is a bug in KahaDB on message add where if a message is marked as a > duplicate the orderIndex next message Id is not rolled back. When a duplicate > is detected and ignored the index is supposed to be rolled back so that the > state isn't broken but in this case the sequence id is still incremented and > this leads to gaps in the order index sequence. > KahaDB tracks pending messages that need to be acknowledged for durable subs > in a SequenceSet and that set is expected to be contiguous and if it isn't it > breaks. The gaps lead to the store reporting messages still exist for > durables and they appear as "stuck" even though there are no messages. > The fix is to roll back the counter (this is already done in another spot) so > it is only incremented if the message is stored. If an existing store is > broken by this bug an index rebuild is likely necessary but then it wouldn't > come back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9435) KahaDB durable sub tracking breaks on duplicate messages
[ https://issues.apache.org/jira/browse/AMQ-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9435: Description: There is a bug in KahaDB on message add where if a message is marked as a duplicate the orderIndex next message Id is not rolled back. When a duplicate is detected and ignored the index is supposed to be rolled back so that the state isn't broken but in this case the sequence id is still incremented and this leads to gaps in the order index sequence. KahaDB tracks pending messages that need to be acknowledged for durable subs in a SequenceSet and that set is expected to be contiguous and if it isn't it breaks. The gaps lead to the store reporting messages still exist for durables and they appear as "stuck" even though there are no messages. The fix is to roll back the counter (this is already done in another spot) so it is only incremented if the message is stored. If an existing store is broken by this bug an index rebuild is likely necessary but then it wouldn't come back. was: There is a bug in KahaDB on message add where if a message is marked as a duplicate the orderIndex next message Id is not rolled back. When a duplicate is detected and ignored the index is supposed to be rolled back so that the state isn't broken but in this case the sequence id is still incremented and this leads to gaps in the order index sequence. KahaDB tracks pending messages that need to be acknowledged for durable subs in a SequenceSet and that set is expected to be contiguous and if it isn't it breaks. The gaps lead to the store reporting messages still exist for durables and they appear as "stuck" even though there are no messages. The fix is to roll back the counter (this is already done in another spot) so it is only incremented if the message is stored > KahaDB durable sub tracking breaks on duplicate messages > > > Key: AMQ-9435 > URL: https://issues.apache.org/jira/browse/AMQ-9435 > Project: ActiveMQ Classic > Issue Type: Bug >Affects Versions: 5.18.3, 6.0.1 >Reporter: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 6.0.2 > > > There is a bug in KahaDB on message add where if a message is marked as a > duplicate the orderIndex next message Id is not rolled back. When a duplicate > is detected and ignored the index is supposed to be rolled back so that the > state isn't broken but in this case the sequence id is still incremented and > this leads to gaps in the order index sequence. > KahaDB tracks pending messages that need to be acknowledged for durable subs > in a SequenceSet and that set is expected to be contiguous and if it isn't it > breaks. The gaps lead to the store reporting messages still exist for > durables and they appear as "stuck" even though there are no messages. > The fix is to roll back the counter (this is already done in another spot) so > it is only incremented if the message is stored. If an existing store is > broken by this bug an index rebuild is likely necessary but then it wouldn't > come back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9435) KahaDB durable sub tracking breaks on duplicate messages
[ https://issues.apache.org/jira/browse/AMQ-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9435: Component/s: KahaDB > KahaDB durable sub tracking breaks on duplicate messages > > > Key: AMQ-9435 > URL: https://issues.apache.org/jira/browse/AMQ-9435 > Project: ActiveMQ Classic > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.18.3, 6.0.1 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 6.1.0, 5.18.4, 6.0.2 > > > There is a bug in KahaDB on message add where if a message is marked as a > duplicate the orderIndex next message Id is not rolled back. When a duplicate > is detected and ignored the index is supposed to be rolled back so that the > state isn't broken but in this case the sequence id is still incremented and > this leads to gaps in the order index sequence. > KahaDB tracks pending messages that need to be acknowledged for durable subs > in a SequenceSet and that set is expected to be contiguous and if it isn't it > breaks. The gaps lead to the store reporting messages still exist for > durables and they appear as "stuck" even though there are no messages. > The fix is to roll back the counter (this is already done in another spot) so > it is only incremented if the message is stored. If an existing store is > broken by this bug an index rebuild is likely necessary but then it wouldn't > come back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
