[
https://issues.apache.org/jira/browse/ARTEMIS-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019825#comment-17019825
]
Christopher L. Shannon commented on ARTEMIS-2375:
-------------------------------------------------
Yeah I realized as I was typing my response that I didn't mention the need to
consume from either consumer. Because you are right simply having an exclusive
binding would be easier but I want a true wildcard consumer which is different.
I agree it might be a little tricky to communicate to users but I do think a
lot of users would want a wildcard consumer feature, just as myself. I'm sure
there are also plenty of use cases for wildcard addresses but anyone coming
from 5.x would expect a wildcard consumer.
In terms of having both, you could support either option with address settings
on the same broker You couldn't support both on the same address but different
addresses could be configured for either a wildcard consumer or wildcard
address. Basically there could be a new flag which has two options for the
address settings...the default option which is wildcard address and another
option to enable which would be to be a wildcard consumer. The option would
only apply to anycast bindings as it doesn't make sense to me to use for
multicast.
In the multicast case things already work correctly as multicast you want a
copy to go anywhere there is a subscription so the wildcard address behavior
matches the expected Topic behavior from 5.x already and it is intuitive.
Trying to turn on a wildcard consumer for a JMS durable sub would break
currently anyways because the queue name for the subscription is the client id
and sub name so trying to associate multiple queues with a durable sub would
not work without changing the queue naming design.
> 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)
