Github user mattrpav commented on the issue:
https://github.com/apache/activemq-artemis/pull/875
I'll detail out the use cases:
1) selectorAware: This allows an interested subscriber to only receive
messages in their queue that match a given selector. This broker pre-filtering
is a server-side optimization which reduces the on-disk requirements for really
busy Virtual Topics.
2) transactedSend: This is a (imho & experience) critical reliability
requirement. In use cases where reliability is a crticial requirement: when a
producer sends a message to the broker, even during non-transacted sessions,
the broker should transact the dispatch to the consumer queues before ack'n the
producer. This ensures no messages are lost in the event of unplanned outage
while a broker is dispatching messages to the consumer queues.
3) concurrentSend: This is a critical performance enhancement for Virtual
Topics where there are a large number of consumer queues. The behavior is that
the broker processes queue dispatch in parallel to consumer queues in order to
improve throughput and lower latency.
[Notes]
i. transactedSend and concurrentSend are often used in conjunction
ii. selectorAware requires some sort of persistence store so selectors are
maintained across restarts (specifically useful during maintenance and failover
testing)
iii. While outside the scope of this PR, I thought I'd mention it here as
it is related-- there has long been a desire to enhance ActiveMQ to support
single-message store. That is, for all subscriptions, only store a single copy
of a message. This becomes really apparent in use cases with a large number of
Virtual Consumers.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
