You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Christopher L. Shannon (JIRA)" <ji...@apache.org> on 2019/01/09 19:30:00 UTC

[jira] [Created] (AMQ-7129) Durable subscription messages can be orphaned when using individual ack mode with KahaDB

Christopher L. Shannon created AMQ-7129:
-------------------------------------------

             Summary: 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
             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)