[
https://issues.apache.org/jira/browse/AMQ-7129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16738576#comment-16738576
]
ASF subversion and git services commented on AMQ-7129:
------------------------------------------------------
Commit 25de20c77ec0bf6cdc699cac2ad50e34ec707453 in activemq's branch
refs/heads/master from Christopher L. Shannon (cshannon)
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=25de20c ]
AMQ-7129 - Properly recover messages from KahaDB for a durable when there are
messages to recover before the stored lastAck value
With individual ack mode we need to check the durable ackPosition
sequence set in the KahaDB index on subsription load to see if there are
earlier messages before the lastAck value that still haven't been acked.
While this normally wouldn't happen it is possible in individual ack
mode
> Durable subscription messages can be orphaned when using individual ack mode
> with KahaDB
> ----------------------------------------------------------------------------------------
>
> Key: AMQ-7129
> URL: https://issues.apache.org/jira/browse/AMQ-7129
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB
> Affects Versions: 5.15.8
> Reporter: Christopher L. Shannon
> Assignee: Christopher L. Shannon
> Priority: Major
> Fix For: 5.16.0, 5.15.9
>
>
> While not a common use case it is possible for a client to use individual
> acknowledge mode on a durable subscription. This allows the following
> scenario:
> # durable subscription is created on a topic
> # 10 messages are published to the topic
> # durable subscription consumes the messages but only acks the 5th message
> # Broker is restarted
> What should happen is there should be 9 messages left that are recovered when
> the subscription comes back online. What actually happens though is that
> messages 1-4 are stuck forever because the KahaDB index will not load them on
> activation. The problem is that the lackAck value that is stored in the index
> is for message 5 so it starts on message 5 for recovery and ignores messages
> 1-4 even though those values are still tracked as part of the ackPositions
> sequence set.
> The solution is that when the subscription is loaded to check if there are
> any ackPositions for that subscription that are earlier than the lastAck
> value and if they are we need to reset the cursor to the first ackPosition.
> Then we need to verify on recovery that any message iterated over actually
> exists as part of the sequence set so we don't load duplicates (this scenario
> happens if multiple subscriptions exist on the topic)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
