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>
Sent: Wednesday, August 2, 2023 1:36 PM
To: 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>> 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

>

>

Reply via email to