[
https://issues.apache.org/jira/browse/QPID-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew MacBean updated QPID-5877:
---------------------------------
Description:
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.
was:
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. This meant that if the
AbstractQueue.getNextAvailableEntry was executing while the IO Thread caused a
rejected message to be requeued 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.
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.
> 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: [email protected]
For additional commands, e-mail: [email protected]
