qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: [jira] Commented: (QPID-572) broker delivers messages out of order
Date Mon, 17 Sep 2007 19:43:14 GMT
Martin Ritchie wrote:
> 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.

I believe a similar scenario can happen based solely on timing, without 
the first message entering the picture. See QPID-601 for details.

On a slight tangent, QPID-545 is a bit of an odd beast. It's not 100% 
apparent to me that it is actually a bug. There seems to be a 
presumption that there can be only one subscriber to a private queue, 
however I don't think this is actually the case. A private queue is 
exclusive to the connection, which means there could be multiple 
sessions from the same connection subscribing to a single queue.

It may be that JMS semantics constrain things sufficiently that the 
presumption is true, however if this is the case then there may need to 
be some reconciliation between JMS and AMQP semantics.


View raw message