[
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.
