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

["Gary Tully (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMQ-7129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16740285#comment-16740285 ] 

Gary Tully edited comment on AMQ-7129 at 1/11/19 11:02 AM:
-----------------------------------------------------------

[~cshannon] I never got a handle on the need for individual ack on a durable sub b/c it is not shared in jms 1.0, for a long time it was only the last ack id that was tracked which meant that this use case did not work historically. With priority support and individual message tracking in the index it is possible now.
There is some redelivery count logic in: org.apache.activemq.broker.region.DurableTopicSubscription#deactivate that will probably break with individual ack if the messages are acked out of order and keepDurableSubsActive is true. In other words, there may be more issues related to this use case b/c it has not been common in the past.
this is forward progress though :-)

Actually - I think in the jdbc store it is just the last ack sequence id per priority that is tracked, so it may be that individual ack on the jdbc store with durable subs won't fly at all b/c there is no separate index.


was (Author: gtully):
[~cshannon] I never got a handle on the need for individual ack on a durable sub b/c it is not shared in jms 1.0, for a long time it was only the last ack id that was tracked which meant that this use case did not work historically. With priority support and individual message tracking in the index it is possible now.
There is some redelivery count logic in: org.apache.activemq.broker.region.DurableTopicSubscription#deactivate that will probably break with individual ack if the messages are acked out of order and keepDurableSubsActive is true. In other words, there may be more issues related to this use case b/c it has not been common in the past.
this is forward progress though :-)

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