[
https://issues.apache.org/jira/browse/QPID-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526370
]
Martin Ritchie commented on QPID-572:
-------------------------------------
Ah, that would do it. as nextSubscriber() returns the next subscriber that is
able to consume this message. This includes this test
subscription.getPreDeliveryQueue().isEmpty()
Which inessence is the selector. Hence why I suggested we needed the additional
subscription.getDeliveryQueue().isEmpty() method. However, it makes more sence
to put that check at the top level as it pertains to the queue as a whole.
I need to write up how the selectors work but the short hand is that each
message that is delivered is evaluated once against each selector using
subscriber via subscriber.hasInterest() if they are interested then the msgs is
added to a PreDelivery Queue that is unique to each subscriber. To prevent two
subscribers getting the same message the message now has a notion of taken().
So the getNextMessage() method checks for this and simply removes any taken
msgs when looking for the next message to send. Ideally we could have a reaper
thread doing some of this but I haven't had time to design that as there are a
number of other tasks such a reaper thread should do. TTL being one of them.
One of my next tasks is to improve some of the technical documentation so I
shall do the CSDM / selector work first to help review the selector changes.
> 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: CSDM.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.
