qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew MacBean (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (QPID-5877) Potential for rejected messages to be resent out of order
Date Fri, 04 Jul 2014 14:52:34 GMT

     [ 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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message