[
https://issues.apache.org/jira/browse/QPID-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527623
]
Rafael H. Schloming commented on QPID-601:
------------------------------------------
I forgot to mention that this issue is related to QPID-572. The original fix
for QPID-572 caused this failure to be exhibited in TopicSessionTest. This was
not because there was anything wrong with the fix per/se, but because the fix
makes it more likely for messages to be queued for async delivery causing the
failure to be more likely.
The modified fix for QPID-572 makes the issue less likely by never attempting
to queue messages for async delivery if the subscription is filtering messages,
however this does not actually fix the problem it simply makes it less likely
to occur and reintroduces the original QPID-572 ordering bug since the
currently published message may skip ahead of messages that are queued for
async deliver when selectors are used.
> messages may be stranded when selectors are used
> ------------------------------------------------
>
> Key: QPID-601
> URL: https://issues.apache.org/jira/browse/QPID-601
> Project: Qpid
> Issue Type: Bug
> Affects Versions: M2, M2.1, M3
> Reporter: Rafael H. Schloming
>
> ConcurrentSelectorDeliveryManager = CSDM
> PDQ = PreDeliveryQueue
> pPDQ = populatePreDeliveryQueue
> Messages may be stranded as a result of the way selectors are implemented.
> When a consumer subscribes to a queue using a filter, CSDM.pPDQ is called to
> move messages from CSDM._messages into the PDQ for that subscription. The
> pPDQ method does this by calling _messages.iterator() and placing matching
> messages into the PDQ of the subscription. The result of _messages.iterator()
> is not guaranteed to reflect concurrent changes made to _messages, and so a
> publish may end up causing a message that matches the subscription to be
> placed onto _messages. This message is then stranded there despite the fact
> that the subscription could accept the message because nothing ever
> reexamines the _messages queue after the initial pPDQ when the consumer
> subscribes.
> One potential fix for this issue would be to make the pPDQ method block
> messages from being pushed onto the _messages queue while it operates. This
> would work, however it would introduce undesirable synchronization for all
> publishers attempting to place messages on the queue.
> So far I can't think of a proper fix for this issue that doesn't involve some
> substantial changes in the data structures for queuing and delivering
> messages.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
