Amazon documentation advises against using JMS selectors:
Avoid Using Message Selectors
It is possible to use JMS selectors to attach filters to topic subscriptions (to route messages to consumers based on their content). However, the use of JMS selectors fills up the Amazon MQ broker's filter buffer, preventing it from filtering messages.
In general, avoid letting consumers route messages because, for optimal decoupling of consumers and producers, both the consumer and the producer should be ephemeral.
I consider JMS selectors a very useful and legitimate feature. I don't quite understand the statement about the "filter buffer." Can someone please clarify the details of the "filter buffer" issue? Is this a common problem for ActiveMQ Classic, or is it specific to the Amazon MQ service implementation? Additionally, is there a way to mitigate this issue through configuration tuning?
There is validity to the advice, the doc is incomplete and lacks full context. Yes, all message brokers have an 'unmatched filter' scenario that can lead to stalled out message flow-- specifically in the slow-consumer-on-a-topic scenario.
When a topic has multiple consumers, and one is slower than the others the topic must keep messages for that one slow consumer at the risk of stalling out the other consumers by having to keep all those messages in memory. This behavior can be modified in ActiveMQ by closing slow consumers, or applying a SubscriptionStrategy to start not delivering messages to the slow consumer as to not impact the other consumers.
Any message flow pattern that includes performing a 'queue-in-a-queue' design runs the risk of undesirable side-effects. This goes for queues and topics. Generally, it is more resilient to filter messages to separate queues per subscriber vs using patterns like like Message Groups, selectors, etc.
ActiveMQ's Virtual Topics allow consumers to register a filter using a selector and then each subscriber gets their own queue with only messages that they want. This is the best of both-- apps can use selectors, avoiding 'queue-in-a-queue' and avoiding 'slow-consumer' causing back pressure.