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

ASF subversion and git services commented on AMQ-6286:
------------------------------------------------------

Commit e02c1a17f83b21cbf42fa9e6e78a891af3edd8bb in activemq's branch 
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=e02c1a1 ]

https://issues.apache.org/jira/browse/AMQ-6286

Create a follow on test showing AMQP respects 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)

Reply via email to