[
https://issues.apache.org/jira/browse/AMQ-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109524#comment-13109524
]
Gary Tully commented on AMQ-3004:
---------------------------------
@Takar
Roelof's patch looks very good and is mostly unobtrusive.
For your use case though I think it only kicks in if all subscriptions are
disconnected, which may not be what you want.
It also needs a junit test case to validate and protect it.
Maybe you can provide the required test case and some update that will make it
work for you?
> Build-up of unwanted messages
> -----------------------------
>
> Key: AMQ-3004
> URL: https://issues.apache.org/jira/browse/AMQ-3004
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.1
> Reporter: Roelof Naude
> Fix For: 5.6.0
>
> Attachments: AMQ-3004.patch
>
>
> One of our installations have several consumers. These consumers subscribe
> for messages from a queue linked to a virtual topic. All consumers supply a
> selector. Some consumers connect, process any persisted messages, then
> disconnect. These connect/disconnect cycles are repeated a few times a day.
> What we've seen is that messages build-up for consumers. These messages does
> not match the supplied selector. The side effect of this was that we ran into
> a situation whereby message "got stuck". Increasing the _maxPageSize_
> property helped. This is unfortunately a short term solution.
> A simple test was constructed whereby *selectorAware* was set to *true*:
> {code:xml}
> <virtualDestinations>
> <virtualTopic name="VirtualTopic.>" prefix="Consumer.*."
> selectorAware="true"/>
> </virtualDestinations>
> {code}
> What we noticed is that:
> # Messages are correctly received by a connected consumer
> # A consumer that connects, disconnects and re-connects later will loose any
> messages that were send in the time period it was disconnected.
> This behaviour was unexpected. From the AMQ documention
> (http://activemq.apache.org/virtual-destinations.html):
> {quote}
> From version 5.4, dispatch from virtual topics to subscription queues can be
> selectorAware such that only messages that match one of the existing
> subscribers are actually dispatched. Using this option prevents the build up
> of unmatched messages when selectors are used by exclusive consumers
> {quote}
> Note: it does not state that the consumer needs to be connected for this
> feature to work.
> Given the test it looks like subscriptions itself are not persisted, thus the
> AMQ broker has no idea that it should enqueue a message for a particular
> subscription queue.
> Would it be possible to add either of:
> # Persist subscription detail, specifically for the case where the
> subscription's selector should be applied to the subscription queue
> # Propagate selectors and the attached subscription queue to the top-level
> virtual topic so that only interested messages can be delivered to the
> intended recipient?
> Anything else we can try, supply or help with?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
