You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Roelof Naude (JIRA)" <ji...@apache.org> on 2010/10/27 15:01:00 UTC
[jira] Created: (AMQ-3004) Build-up of unwanted messages
Build-up of unwanted messages
-----------------------------
Key: AMQ-3004
URL: https://issues.apache.org/activemq/browse/AMQ-3004
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.4.1
Reporter: Roelof Naude
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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-3004) Build-up of unwanted messages
Posted by "Roelof Naude (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roelof Naude updated AMQ-3004:
------------------------------
Attachment: AMQ-3004.patch
The attached patch solves the issue for the most part. Consumers need to connect at least once for the selector to be cached. The cached selector will be persisted to the configured file every 10min. It is re-loaded during startup.
{code:xml}
<broker>
.
.
.
<plugins>
<spring:ref local="subQueueSelectorCacheBroker"/>
</plugins>
.
.
.
</broker>
<spring:bean id="subQueueSelectorCacheBroker" class="org.apache.activemq.plugin.SubQueueSelectorCacheBrokerPlugin">
<spring:property name="persistFile" value="file:${jboss.server.data.dir}/activemq/selectorCache.dat"/>
</spring:bean>
{code}
> Build-up of unwanted messages
> -----------------------------
>
> Key: AMQ-3004
> URL: https://issues.apache.org/activemq/browse/AMQ-3004
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.1
> Reporter: Roelof Naude
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-3004) Build-up of unwanted messages
Posted by "Roelof Naude (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roelof Naude updated AMQ-3004:
------------------------------
Component/s: Broker
> Build-up of unwanted messages
> -----------------------------
>
> Key: AMQ-3004
> URL: https://issues.apache.org/activemq/browse/AMQ-3004
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.1
> Reporter: Roelof Naude
>
> 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.
-
You can reply to this email to add a comment to the issue online.