[
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. 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.
was:
The AbstractQueue.getNextAvailableEntry implementation has the potential to
choose the wrong node when lastSeen and releasedNode are the same.
The logic currently uses the compareTo impl to determine which node to select
but uses the > operator 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. 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.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
