qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie" <ritch...@apache.org>
Subject Re: [jira] Commented: (QPID-572) broker delivers messages out of order
Date Fri, 14 Sep 2007 21:58:17 GMT
IMO the modified fix is the correct fix. As the TopicSessionTest will
still fail with the first fix.

The logic is as follows:

Summarising the Topic Session Test:

A subscribe (Sn) is created that receives all messages on the topic
A subscriber (Ss) is created with a selector.

A message (m1) is sent to the topic which is received by Sn
The CSDM logic for Ss is as follows:
A call to nextSuscriber(m1) is made to locate any subscribers on this
queue (which given we are talking "topics" is exclusive queues with
only the give S attached.

However, in this case Ss has a selector that doesn't match m1. So
nextSubscrier(m1) will return null. As there are no subscribers on
this queue that are willing and able to receive the message.

The two fixes for CSDM both are true here:
First Fix:
if (s == null || hasQueuedMessages() )
Modified Fix:
if (s == null || (!s.filtersMessages() && hasQueuedMessages() ))

So s is null so queuing is performed, This actually is a bug
(QPID-545) as this message will NEVER be consumed as it doesn't match
Ss' filter. However it will be added to the mail queue.

On receipt of a second message (m2) that does match the filter, the
first fix will fail as s is now non null and hasQueuedMessages()
returns true. Causing queuing BUT there is no queuing on Ss. So TST
will fail as it expects to receive m2. The Modified fix prevents
checking the main Queue when s is a filtering subscriber as
nextSubscriber has already checked the PDG for content.

QPID-545 would prevent the need for the modified fix. However, I have
not had time to write a test to verify my solution for QPID-545.

On 14/09/2007, Rafael H. Schloming (JIRA) <qpid-dev@incubator.apache.org> wrote:
>
>     [ https://issues.apache.org/jira/browse/QPID-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527624
]
>
> Rafael H. Schloming commented on QPID-572:
> ------------------------------------------
>
> I believe the original fix for this issue is actually more correct than the modified
fix, although the modified fix might be considered a reasonable M2 workaround for QPID-601.
Please see my comments on QPID-601 for details.
>
> > 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
> >         Attachments: QPID-572-testcase.patch
> >
> >
> > 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.
>
>


-- 
Martin Ritchie

Mime
View raw message