[
https://issues.apache.org/jira/browse/QPID-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew MacBean resolved QPID-5877.
----------------------------------
Resolution: Fixed
> Potential for rejected messages to be resent out of order
> ---------------------------------------------------------
>
> Key: QPID-5877
> URL: https://issues.apache.org/jira/browse/QPID-5877
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Reporter: Andrew MacBean
> Assignee: Andrew MacBean
> Fix For: 0.29
>
>
> Based on investigation of a test failures in the
> FailoverBehaviourTest#testTransactionRolledBackExceptionThrownOnCommitAfterFailoverOnMessageReceiving()
> it was observed that the messages consumed by the client after failover were
> out of order.
> This manifested itself because of a client bug (QPID-5878) that means that
> after failover the highestDeliveryTag was not rest and so rejects were send
> spuriosly for messages previously delivered.
> This meant that if the AbstractQueue.getNextAvailableEntry was executing
> while the IO Thread caused a rejected message to be requeued (and updated
> lastSeen node) the logic that finally decides the next entry node would
> incorrectly continue if the lastSeen and releasedNodes where the very same
> queue entry. This would mean that the next selected by the broker would
> break the ordering sequence expected.
> Basically, the AbstractQueue.getNextAvailableEntry implementation has the
> potential to choose the wrong node when lastSeen and releasedNode are the
> same as the compareTo impl to determine which node to select but uses the >
> operator rather than >= and so wont select releasedNode in the case were that
> and lastSeen are the same.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
