Asynchronous listening of JMS Message from Oracle AQ - Buffered Queue not working

260 Views Asked by At

I've written a sample application for a producer and consumer scenario using an Oracle AQ "buffered" queue. From the producer I am able to send the message to the buffered queue. I have registered the message listener (which implements javax.jms.MessageListener) for the respective queue. My listener is not able to process the message. Do I need to do anything specific in order to make it work for the "buffered" queue?

Note: I am able to see this message in the AQ $My_QueueTable_Name with msg_state as MEMORY. Also the same listener is working fine if I send the message to normal queue.

Below method is registering the MessageListener during Spring Boot application startup.

@PostConstruct
public void registerEndPoints() {
    try {
        JmsListenerEndpointRegistry registry = new JmsListenerEndpointRegistry();
        SimpleJmsListenerEndpoint endPoint = null;
        ConnectionFactory cf = null;


        for (String queueName : queueNames) {           
            cf = connectionFactory();
            endPoint = new SimpleJmsListenerEndpoint();
            endPoint.setId(queueName);
            endPoint.setDestination(queueName);
            endPoint.setConcurrency(concurrencyLimit);
            endPoint.setMessageListener(new JmsMessageListener(cf, sleepTimeInMillis));

            registry.registerListenerContainer(endPoint, defaultJmsListenerContainerFactory(cf));
        }

        registry.start();
        System.out.println("JMS Listener registered for " + queueNames.length
                + " Request Queues for the Messaging Server : " + messagingServerName);

    } catch (JMSException e) {
        System.out.println("JMS Listener registration failed : validate before proceed test");
        e.printStackTrace();
    }

}

For those unfamiliar with Oracle AQ a "buffered" queue will keep messages in memory while a normal queue which will store the messages in the database irrespective of delivery mode (i.e. persistent / non-persistent). In my case, a huge volume of message processing will happen, and that's the reason going with the buffered queue.

0

There are 0 best solutions below