Major 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.
Attachments
Issue Links
- is duplicated by
-
QPID-5811 FailoverBehaviourTest.testTransactionRolledBackExceptionThrownOnCommitAfterFailoverOnMessageReceiving failed with unexpected message order
-
- Resolved
-