[jira] Commented: (QPID-572) broker delivers messages out of order

["Martin Ritchie (JIRA)" <qp...@incubator.apache.org>]

    [ https://issues.apache.org/jira/browse/QPID-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525726 ] 

Martin Ritchie commented on QPID-572:
-------------------------------------

the nextSubscriber method used by the deliver(...) method MUST only return a subscriber that is ready and able to receive a message.
i.e. it is not suspended and there are no queued messages for that subscriber.

The bug is that the SubscriptionImp only checks if it is queuing msgs when there is a filter in place. If there is no filter it doesn't check the main queue for messages. 

            if (!(subscription.isSuspended() || subscription.wouldSuspend(msg)))
            {
                if (subscription.hasInterest(msg))
                {
                    // if the queue is empty then this client is ready to receive a message.
                    //FIXME the queue could be full of sent messages.
                    // Either need to clean all PDQs after sending a message
                    // OR have a clean up thread that runs the PDQs expunging the messages.
>>>>>        if (!subscription.filtersMessages() || subscription.getPreDeliveryQueue().isEmpty())

// Should be something like this:
/// if there is a filter does this subscription have any pending messages || if there are no messages pending(This method doesn't exist).
                    if ((subscription.filtersMessages() && subscription.getPreDeliveryQueue().isEmpty() ) ||  subscription.getDeliveryQueue().isEmpty )



> broker delivers messages out of order
> -------------------------------------
>
>                 Key: QPID-572
>                 URL: https://issues.apache.org/jira/browse/QPID-572
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker
>    Affects Versions: M2, M2.1, M3
>            Reporter: Rafael H. Schloming
>
> ConcurrentSelectorDeliveryManager will sometimes deliver messages out of order. This is caused by the code in deliver(...) that attempts to short-circuit message queuing when there is an available subscription. This code can result in the currently published message skipping ahead of queued messages causing out of order delivery. Although unrelated to transactions, I have observed this failure occuring in TransactedTest both in testCommit and testRollback. Normally it does not happen very frequently, however placing a Thread.sleep(500) in the async delivery thread will cause the failure to occur almost all the time.
> I tried fixing the problem by only attempting synchronous delivery when there are no queued messages, however this appears to break other tests that use selectors. This makes me suspect that the selector implementation is somehow incorrectly coupled to synchronous delivery.
> I have only verfied this issue on the trunk, however I believe it effects M2 as well.

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