qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rafael H. Schloming (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Commented: (QPID-601) messages may be stranded when selectors are used
Date Fri, 14 Sep 2007 20:30:32 GMT

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

View raw message