[
https://issues.apache.org/jira/browse/AMQ-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved AMQ-6286.
-----------------------------
Resolution: Fixed
strictOrderDispatch=true - for a single consumer, re-dispatched messages will
be inserted at the head of the dispatch list.
Note: this does not work if prioritizedMessages=true, in that case the ordering
is determined by the current visible message priority, irrespective of previous
dispatch order.
> Queue order lost on repeated redelivery
> ---------------------------------------
>
> Key: AMQ-6286
> URL: https://issues.apache.org/jira/browse/AMQ-6286
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.13.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Labels: order
> Fix For: 5.14.0
>
>
> When a consumer prefetches messages or consumes and does not ack in pull
> mode, on close, any messages that have not been acked end up in on the broker
> in the already delivered list.
> These messages get dispatched first. However, if these messages are
> unconsumed again, they get appended to the dispatched list.
> This makes sense when there are multiple consumers, A gets 10, B gets 10, A
> closes, there are 10 to redeliver, B closes, there are now 20 to redeliver.
> the order should be preserved.
> However if there is a single consumer this breaks.
> Consider:
> publish 100 to Q
> consume 50 and rollback/close with all unacked, expect 0-49
> consume 10 and rollback/close with all unacked, expect 0-9
> consume 10 more ... expect 0-9 but get 10-19!
> In concert with the strictOrderDispatch policy, I think we should be able to
> support the natural expectation here.
> The scenario presents its self with prefetched messages where the prefetch
> varies or more naturally with a single consumer that consumed in various
> transaction batches. In the transacted case, two failures would result in
> compromised queue ordering.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
