[jira] [Commented] (ARTEMIS-2375) JMS, Wildcard destination consumer, and Acknowledgements going to wrong queue

["Christopher L. Shannon (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARTEMIS-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17016071#comment-17016071 ] 

Christopher L. Shannon commented on ARTEMIS-2375:
-------------------------------------------------

I ran into this issue today and not really sure how to resolve it at the moment.  But it's a big issue for me as it is completely different behavior than how 5.x works so we might need to have an optional way to customize the routing behavior here so that a wildcard consumer can consumer the messages off the actual queues and doesn't get a copy in the wildcard queue.  That, in combination with turning off routing in WildcardConfiguration should fix the issue for people.

> 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)