[
https://issues.apache.org/jira/browse/ARTEMIS-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16882195#comment-16882195
]
Justin Bertram commented on ARTEMIS-2422:
-----------------------------------------
Lots of short-lived consumers with selectors makes queue scanning issues worse,
but the queue scanning problem exists even without such consumers. In general I
discourage users from consuming messages from a queue with a filter/selector
and instead recommend a multicast address with filtered queues (or durable
topic subscriptions with selectors in JMS terms) as this avoids scanning
completely.
I don't think the existing broker plugin interface provides deep enough hooks
to implement this kind of functionality and I'm not familiar enough with the
underlying redistribution logic to provide clear guidance at this point. I
imagine if it was easy to implement it would have been already despite the
performance pitfalls.
One option to consider is consolidating your cluster to a single node. Artemis
has very good performance and a single broker hand handle (literally) millions
of messages a second in certain use-cases. Did you benchmark your application
and conclusively determine that you needed a cluster of 2 nodes? If not, it may
be worth looking at using just a single broker. Usually use-cases with
consumers on queues with selectors are fairly low-performance anyway.
> Support Message Redistribution based on Message Filters/Selectors
> -----------------------------------------------------------------
>
> Key: ARTEMIS-2422
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2422
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
> Affects Versions: 2.9.0
> Reporter: Sebastian T
> Priority: Major
>
> We are running an active/active Artemis clusters (with ON_DEMAND message
> loadbalacing and message redistribution enabled) with a TCP loadbalancer in
> front. Our customers use consumers with message selectors/filters. When
> applications have to reestablish their connection to the broker (e.g. b/c of
> redeployment, infrastructure issues, etc) it is not guaranteed that their
> consumers end-up on the same cluster node as before.
> Since message filters are only taken in consideration on first-time
> distribution (e.g. the moment the message arrives on a broker) or when ALL
> consumers of a queue on a particular node are removed, we sometimes end up
> with with a situation where messages waiting on one node to be consumed,
> while the matching consumer is starving on another node.
> A related discussion from 2015:
> [http://activemq.2283324.n4.nabble.com/artemis-cluster-don-t-redistribute-message-td4703503.html]
> We did run RabbitMQ in active/active configurations before and did not have
> to worry about this particular issue.
> What we are looking for is an option that when a consumers is disconnected
> from a queue and there are messages left in the queue that were matched by
> this consumer and there are no other matching local consumer message then
> redistribution of these messages should be triggered.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
