[
https://issues.apache.org/jira/browse/ARTEMIS-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17018582#comment-17018582
]
Christopher L. Shannon commented on ARTEMIS-2375:
-------------------------------------------------
Right, the goal is to not break existing users. I'm ok calling it a new
feature or enhancement, it doesn't really matter.
Obviously the broker is multiple protocols but I am coming from this from a JMS
standpoint which is a core feature of the broker. The issue is that while I
get it's just a wildcard address, the reality is when you create a JMS consumer
on a JMS wildcard queue, as a user I expect it to be a wildcard consumer.
That's how 5.x and other JMS brokers I have used work. The idea of a queue
with JMS is you only consume the message one time. Except that with the
current behavior if you have one consumer on a JMS queue and another consumer
on a wildcard JMS queue (so a wildcard address that matches the other address)
and a message is sent to the first queue then both consumers will get the
message which makes no sense to me as you have broken the whole point of
point-to-point.
I should note that for the Topic use case (multicast) things work as expected.
In that case the current model works great as you want the messages to be
consumed by both consumers.
My fix is pretty straight forward and configurable of course to be enabled or
disable (off by default). Essentially the way I'm fixing it is like this:
# Split up the routingEnabled flag in the address configuration to be two
flags, one for anycast and one for multicast. The idea here is we would want
to turn off routing to the wildcard queue for anycast bindings but for
multicast we want to preserve existing behavior as things work as expected
already for topics.
# Now that messages won't be routed to the wildcard address anymore (except
when sent directly to the wildcard address of course) then when the binding is
anycast, update ServerConsumer to be able to consume from more than one queue
if configured to do so. So on creation the consumer on the server would
register itself as a consumer on all matching queues for the wildcard.
# Be able to add/remove new matching queues as they come online.
Obviously there are some more details to work out such as how to manage the
multiple queues and manage things like acknowledgements in an efficient way
which I've been working on. Also the goal is to make sure performance is not
really impacted for existing users and even if this new feature is turned on to
be as efficient as possible since it's in the hot path.
> JMS, Wildcard destination consumer, and Acknowledgements going to wrong queue
> -----------------------------------------------------------------------------
>
> Key: ARTEMIS-2375
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2375
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Affects Versions: 2.9.0
> Reporter: Craig Schmidt
> Assignee: Justin Bertram
> Priority: Major
>
> I have an ActiveMQ server set up where I have multiple (and unbounded) queues
> which differ only in the last component. e.g. myqueue.1, myqueue.2,
> myqueue.4, etc. The last component is from a database that will have a
> varying set of customers defined - and I want to set up one queue for each
> customer. (I want a separate queue - the third party we're talking to needs
> throttling at our 'customer' level.
> The address setting looks like this in broker.xml:
> {code:xml}
> <address-setting match="myqueue.#">
> <dead-letter-address>myqueue.DLQ</dead-letter-address>
> <expiry-address>myqueue.ExpiryQueue</expiry-address>
> <redelivery-delay>500</redelivery-delay>
> <max-size-bytes>-1</max-size-bytes>
> <message-counter-history-day-limit>10</message-counter-history-day-limit>
> <address-full-policy>PAGE</address-full-policy>
> <auto-create-queues>true</auto-create-queues>
> <auto-create-addresses>true</auto-create-addresses>
> <auto-create-jms-queues>true</auto-create-jms-queues>
> <auto-create-jms-topics>true</auto-create-jms-topics>
> <max-delivery-attempts>3</max-delivery-attempts>
> </address-setting>
> {code}
> I have a producer that creates the queue name based on the customer key, and
> uses JmsMessagingTemplate.convertAndSent(queueName, message). I have a
> consumer annotated like this:
> {code:java}
> @JmsListener(destination = "myqueue.#", containerFactory =
> "throttledLongCodeFactory")
> public void processLongCodeMessage1(Session session, Message<MessageRequest>
> message) throws JMSException {
> //... do the message handling - no ActiveMQ accesses in here...
> session.commit();
> }
> {code}
> FWIW, here's the code for the throttledLongCodeFactory:
> {code:java}
> @Bean public DefaultJmsListenerContainerFactory
> throttledLongCodeFactory(DefaultJmsListenerContainerFactoryConfigurer
> configurer) {
> ActiveMQConnectionFactory connectionFactory =
> createActiveMQConnectionFactory();
> // For throttling. Used to limit the number of messages a consumer will
> handle per second. Default is -1.
> Integer maxConsumerRate =
> appProperties.getArtemis().getLongCode().getMaxConsumerRate();
> if (maxConsumerRate != null) {
> connectionFactory.setConsumerMaxRate(maxConsumerRate);
> }
> // This provides all boot's default to this factory, including the message
> converter
> DefaultJmsListenerContainerFactory factory = new
> DefaultJmsListenerContainerFactory();
> configurer.configure(factory, connectionFactory);
> return factory;
> }
> {code}
> What I'm finding in looking at the ActiveMQ Management Console is that the
> consumer ACK's are going to a (new) queue "myqueue.#" (i.e. literally has the
> '#' in the name), rather than the actual source queue for each message. In
> the consumer, I can see the actual source queue name (e.g. "myqueue.2") by
> inspecting the ClientMessageImpl field 'address'. What I'd like is for the
> ACK's to go to the source queue. the way it is, my specific queues are just
> building up the number of messages they contain, which isn't doing the
> Artemis server memory any good.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
