qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Assigned: (QPID-2120) [race condition] asynchronous delivery and message rejection can result in out of order message deilvery
Date Thu, 01 Oct 2009 08:00:27 GMT

     [ https://issues.apache.org/jira/browse/QPID-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Martin Ritchie reassigned QPID-2120:
------------------------------------

    Assignee: Martin Ritchie

> [race condition] asynchronous delivery and message rejection can result in out of order
message deilvery
> --------------------------------------------------------------------------------------------------------
>
>                 Key: QPID-2120
>                 URL: https://issues.apache.org/jira/browse/QPID-2120
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker
>            Reporter: Martin Ritchie
>            Assignee: Martin Ritchie
>            Priority: Blocker
>             Fix For: 0.6
>
>
> The recent fixes for rollback QPID-2116 and QPID-1871 highlighted a race condition in
the broker.
> When messages are rejected asynchronous delivery is started to see if any current consumer
wants the message. The 0-8 java client rejects messasges in the following order: Prefetch
then Delivered. As a result the RollbackOrderTest#testOnMessage that receives one message
then rolls back can receive the second message ahead of the first message. 
> This was possible because we retrieved the node (getLastSeenNode) then later checked
if we were suspended. So with a suitable sleep in the client between rollback and the restarting
of the Channel Flow state (=true) the problem can be seen to vanish. What was occuring was
the async process retreived the last seen (message 2) the last Reject is processed releasing
Message 1. The Async process is still attempting delivery of Message 2 when the Flow=true
arrives and so it can deliver Messasge 2.
> The fix is to ensure that a suspended client cannot enter a path where it could deliver
a message. 
> This is safe as all Rejects will be full processed before the Flow=true is sent so any
process attempting to getLastSeenNode() must do so AFTER a sub.isSuspended() check. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message