Your code suggests you didnt do either of the suggestions, which were: - Use the JMS 2 API for creating your shared subscriptions (which is effectively what you are already doing). - Use an FQQN address with a Topic consumer.
Your consumer is using a Queue destination, which is different.You need a Topic consumer so it is considered 'multicast' like a topic subscription backing queue, and aligns with the topic/multicast publisher. I should note that there were changes in this 'FQQN topic consumer' area recently [1] to address issues with also using selectors at the same time, so you will definitely hit issues if you do that with the old 2.19.1 client. [1] https://issues.apache.org/jira/browse/ARTEMIS-4259 On Wed, 2 Aug 2023 at 19:40, PAS Filip <filip....@sodexo.com.invalid> wrote: > > Small correction to the phrase: > > > I don’t see that the queue is created under the topic when looking in the > console. > > > Should be: > > > I see that the queue is created under the topic when looking in the console. > > > From: PAS Filip <filip....@sodexo.com.INVALID> > Sent: Wednesday, August 2, 2023 8:34 PM > To: users@activemq.apache.org > Subject: RE: Unexpected behaviour with virtual topics > > Hi Robbie, Thanks for the feedback! On copying the code into the ide, it > completed the imports automatically and I hadn’t noticed the package of the > activemq factory changed to the artemis one. From your explanation I > understand that this works > ZjQcmQRYFpfptBannerStart > External sender > Check the sender and the content are safe before clicking links or open > attachments. > ZjQcmQRYFpfptBannerEnd > > Hi Robbie, > > > > Thanks for the feedback! > > On copying the code into the ide, it completed the imports automatically and > I hadn’t noticed the package of the activemq factory changed to the artemis > one. > > From your explanation I understand that this works only with the openwire > protocol used by the old 5.x activemq clients. > > > > Based on your feedback that FQDN can be used instead I updated the virtual > topic example to use FQDN. (still using the artemis jms client). > > The topic publishes on VirtualTopic.Orders and the queue to consume from > becomes VirtualTopic.Orders::Consumer.A.VirtualTopic.Orders. > > Running the example this way I still am not getting the desired result. > > I don’t see that the queue is created under the topic when looking in the > console. > > The message doesn’t seem to get delivered as the test fails with no message > received. (see error below) > > I also tried changing the order of creating the destination in the example to > first create the topic and then the queue with the consumer, which yields the > same result. > > > > The log shows the following: > > > > 20:06:53.956 [main] DEBUG o.a.activemq.artemis.core.client - The queue > VirtualTopic.Orders::Consumer.A.VirtualTopic.Orders was created automatically > > Sent message with ID: ID:5c95a887-315f-11ee-8b06-00090faa0001 to Topic: > VirtualTopic.Orders > > > > And the test fails with the message: > > EXAMPLE FAILED - No message received from Queue: > VirtualTopic.Orders::Consumer.A.VirtualTopic.Orders > > > > The topic is configured in the broker as follows: > > > > <addresses> > > <address name="VirtualTopic.Orders"> > > <multicast/> > > </address> > > </addresses> > > > > This is basically the same behaviour I get when using the activemq naming > conventions. > > > > When I change the configuration to: > > > > <address name="VirtualTopic.Orders"> > > <multicast> > > <queue name="Consumer.A.VirtualTopic.Orders" > /> > > </multicast> > > </address> > > The test succeeds however we need the possibility to add consumers for queues > of the multicast address that aren’t predefined. > > (Note that this test also succeeded using the activemq 5.x naming conventions > when configured this way) > > From reading the docs I was under the impression that this should be possible > however my tests seem to indicate it only works if the queue is predefined as > a multicast under the address. > > Can you confirm that this approach is correct and should work or what it is > that I’m missing? > > Do queues have to be predefined? Can we not dynamically add extra consumers? > > Are there any alternatives? Would it be possible to use openwire protocol by > the artemis jms client and have it work? > > > > To be complete I provided the whole snippet of code of the updated example > below: > > > > import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory; > > import org.apache.activemq.artemis.jms.client.ActiveMQTopic; > > import javax.jms.*; > > > > public static void main(final String[] args) throws Exception { > > Connection connection = null; > > try { > > > > ConnectionFactory cf = new ActiveMQConnectionFactory(); > > > > connection = cf.createConnection(); > > Session session = connection.createSession(false, > Session.AUTO_ACKNOWLEDGE); > > > > //create consumer on queue that is used by the Virtual Topic > > Queue queue = > session.createQueue("VirtualTopic.Orders::Consumer.A.VirtualTopic.Orders"); > > MessageConsumer messageConsumer = session.createConsumer(queue); > > connection.start(); > > > > //send message to virtual topic > > Topic topic = session.createTopic("VirtualTopic.Orders"); > > MessageProducer producer = session.createProducer(topic); > > TextMessage message = session.createTextMessage("This is a text > message"); > > producer.send(message); > > > > System.out.println("Sent message with ID: " + > message.getJMSMessageID() + " to Topic: " + topic.getTopicName()); > > > > //consume the message from the backing queue > > TextMessage messageReceived = (TextMessage) > messageConsumer.receive(5000); > > > > if (messageReceived != null) { > > System.out.println("Received message with ID: " + > messageReceived.getJMSMessageID() + " from Queue: " + queue.getQueueName()); > > } else { > > //unexpected outcome > > throw new RuntimeException("EXAMPLE FAILED - No message > received from Queue: " + queue.getQueueName()); > > } > > } finally { > > if (connection != null) { > > connection.close(); > > } > > } > > } > > > > Thanks in advance for any help you can provide. > > > > Regards, > > > > Filip > > > > From: Robbie Gemmell > <robbie.gemm...@gmail.com<mailto:robbie.gemm...@gmail.com>> > > Sent: Wednesday, August 2, 2023 1:36 PM > > To: users@activemq.apache.org<mailto:users@activemq.apache.org> > > Subject: Re: Unexpected behaviour with virtual topics > > > > I believe the virtualTopicConsumerWildcards stuff only applies for Openwire > protocol clients (i. e ActiveMQ 5. x), as used in the example you referenced. > Your description and log snippets note you are trying to use that with the > Artemis Core > > ZjQcmQRYFpfptBannerStart > > External sender > > Check the sender and the content are safe before clicking links or open > attachments. > > ZjQcmQRYFpfptBannerEnd > > > > I believe the virtualTopicConsumerWildcards stuff only applies for > > > > Openwire protocol clients (i.e ActiveMQ 5.x), as used in the example > > > > you referenced. > > > > > > > > Your description and log snippets note you are trying to use that with > > > > the Artemis Core JMS client instead, meaning those bits just dont > > > > apply. You should use the JMS 2 APIs for creating shared subscriptions > > > > to create+consume from new shared subscription backing queues, or > > > > alternatively you could use an FQQN address with a Topic subscriber. > > > > > > > > (Obligatory note that 2.19.1 is already an older release at this > > > > point, and there won't be any more 2.19.x releases. Aside, the next > > > > JDK LTS, 21, is due for RC1 next week...previously with JDK17, RC1 > > > > became the GA). > > > > > > > > On Tue, 1 Aug 2023 at 21:12, PAS Filip > <filip....@sodexo.com.invalid<mailto:filip....@sodexo.com.invalid<mailto:filip....@sodexo.com.invalid%3cmailto:filip....@sodexo.com.invalid>>> > wrote: > > > > > > > > > > Hello, > > > > > > > > > > I'm running into a strange issue I cannot explain and was hoping someone > > could shed some light on the issue. > > > > > > > > > > I'm running an artemis broker 2.28.0 using the artemis jms client 2.19.1 > > (the latest java 8 compatible client, my client must be java 8 > > unfortunately). > > > > > > > > > > I've created a broker using all standard settings and copied the broker > > configuration from the openwire virtual topic example, specifically the > > acceptor and the topic configuration: > > > > > > > > > > <acceptor > > name="artemis">tcp://0.0.0.0:61616?virtualTopicConsumerWildcards=Consumer.*.%3E%3B2</acceptor> > > > > > > > > > > <addresses> > > > > > <address name="VirtualTopic.Orders"> > > > > > <multicast/> > > > > > </address> > > > > > </addresses> > > > > > > > > > > If I copy the code from the virtual topic example into my project and run > > it the test fails. > > > > > The message sent to VirtualTopic.Orders is not delivered to the consumer > > of the Consumer.A.VirtualTopic.Orders destination. > > > > > The destination Consumer.A.VirtualTopic.Orders is created as a queue and is > > visible as a separate address and not visible under the topic in the > > console. > > > > > In the log I found this message: > > > > > > > > > > DEBUG o.a.activemq.artemis.core.client - The queue > > Consumer.A.VirtualTopic.Orders was created automatically. > > > > > > > > > > To make the example work I changed the configuration in the broker.xml to: > > > > > > > > > > <address name="VirtualTopic.Orders"> > > > > > <multicast> > > > > > <queue > > name="Consumer.A.VirtualTopic.Orders" /> > > > > > </multicast> > > > > > </address> > > > > > > > > > > The log statement then disappears, and the behaviour is as expected. > > > > > > > > > > I'm trying to figure out where this difference in behaviour comes from. > > > > > Is there something in the maven plugin used to bootstrap the broker for the > > test that does some additional configuration that would change this > > behaviour? > > > > > > > > > > In my use case we need to get this configuration working with the > > <multicast/> tag so we can add additional queues that will receive the > > messages from the topic > > > > > Without having to predefine them all in the configuration. > > > > > > > > > > > > > > > Anyone have any ideas or suggestions that would greatly be appreciated. > > > > > > > > > > Regards, > > > > > > > > > > Filip > > > > > > > > > >
