activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-6286) Queue order lost on repeated redelivery
Date Fri, 13 May 2016 14:51:13 GMT

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

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

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

https://issues.apache.org/jira/browse/AMQ-6286 - variant on test with n consumers sharing
a session


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

Mime
View raw message